The coordination problem presented by C-to-C applications is addressed most directly by Balakrishnan et al. in their work on the Congestion Manager (CM) [3,1,2]. CM provides a framework for different transport-level protocols to share information on network conditions, specifically congestion, thus allowing substantial performance improvements. We note, however, that CM flows share the same end-to-end path, while C-to-C flows share only a common intermediary path. The fact that C-to-C senders do not reside on the same host significantly limits the extensibility of the CM architecture to our problem context. CM offers applications sharing the same macroflow a system API and callback mechanisms for coordinating send events. Implementing this scheme using message passing between hosts is at best problematic.
Furthermore, CM makes use of a scheduler to apportion bandwidth among flows. In [3], this is implemented using a Hierarchical Round Robin (HRR) algorithm. We might extend this scheme to the C-to-C context by placing the scheduler at the AP. Doing so, however, results in several problems. First, packet buffering mechanisms are required which, along with scheduling, add complexity to the AP and hurt forwarding performance. Second, packet buffering at the AP lessens endpoint control over send events since endpoint packets can be queued for an indeterminate amount of time. Balakrishnan et al. deliberately avoid buffering for exactly this reason, choosing instead to implement a scheduled callback event. Finally, scheduler configuration is problematic since C-to-C applications are complex and may continually change the manner in which aggregate bandwidth is apprortioned among flow endpoints.
In [9], Kung and Wang propose a scheme for aggregating traffic between two points within a backbone network, and applying the TCP congestion control algorithm to the whole bundle. The mechanism is transparent to applications and does not provide a way for a particular application to make interstream tradeoffs.
Pradhan et al. propose a way of aggregating TCP connections sharing the same traversal path in order to share congestion control information [12]. Their scheme takes a TCP connection and divides it into two separate (``implicit'') TCP connections: a ``local subconnection'' and a ``remote subconnection.'' This scheme, however, breaks the end-to-end semantics of the transport protocol.
[14] describes a scheme for sharing congestion information across TCP flows from different hosts. This work is similar to ours in that a mechanism is introduced within the network itself to coordinate congestion response across a number of different flows which may not share a complete end-to-end path. Their mechanism does not provide the application with information about flows as an aggregate, however, and focuses on optimizing TCP performance by avoiding slow-start and detecting congestion as early as possible.
Finally, Seshan et al. propose the use of performance servers that act as a repository for end-to-end performance information [15]. This information may be reported by individual clients or collected by packet capture hosts, and then made available to client applications using a query mechanism. The time granularity of performance information is coarse compared to CP, however, since it is intended to enable smart application decisions on connection type and destination, and not ongoing congestion responsiveness. In addition, their work does not associate heterogeneous flows belonging to the same application, or consider the performance of flow aggregates.