Networking Requirements of C-to-C Applications

A useful metaphor for visualizing the networking requirements of C-to-C applications is to view the communication between clusters as a rope with frayed ends. The rope represents the aggregate data flow between clusters. Each strand represents one particular flow between endpoints. At the ends of the rope, each frayed strand represents a separate path between an endpoint and its local AP. The strands come together at the AP's to form a single aggregate object. While each strand is a separate entity, they share a common fate and purpose when braided together.

With this metaphor in mind, we identify several important networking requirements of C-to-C applications:

• Preserved end-to-end semantics.
  The transport-level protocol (i.e., TCP, UDP, RTP, RAP, etc.) that is used by each flow is specific to the communication requirements of the data within the flow and the role it plays within the application. Thus, each transport-level protocol should maintain the appropriate end-to-end semantics and mechanisms. For example, if a data flow contains control information that requires in-order, reliable delivery, then the transport-level protocol used (e.g., TCP) should provide these services on an end-to-end basis.

• Global coordinated measurements of throughput, delay, and loss.
  The application is interested in overall performance which may involve complex interstream adaptation strategies in the face of changing network conditions. Throughput, delay, and loss should be measured across all flows associated with the application as an aggregate. Furthermore, the behavior of individual transport-level protocols must reflect both the end-to-end semantics associated with the protocol as well as application-level adaptation strategies. To achieve this, we need to separate the adaptive dynamic behavior of each transport-level protocol from the mechanisms used to measure current network conditions.

• TCP-friendliness.
  While the C-to-C application is free to prioritize how bandwidth is allocated among its streams, the total bandwidth used needs to be responsive to congestion. The emerging gold-standard for evaluating responsiveness is TCP-friendliness. Intuitively, a flow of data is considered TCP-friendly if it consumes as much bandwidth as a competing TCP flow consumes given the same network conditions. The advantage of using TCP-friendliness as a standard by which to measure the congestion response of a protocol (or in our case, the aggregate behavior of a set of protocols) is that it ensures ``fairness'' with the large majority of Internet traffic (including HTTP) that uses TCP as an underlying data transport protocol.

• Information about peer flows.
  Individual streams within the C-to-C application may require knowledge about other streams of the same application. This knowledge can be used to determine the appropriate adaptive behavior given application-level knowledge about interstream relationships. For example, an application may want to establish a relationship between two flows of data such that one flow consumes twice as much bandwidth as the other.

• Flexibility for the application.
  A C-to-C application should be free to exploit trade-offs without constraint. That is, a coordination mechanism should not preclude dynamic changes in bandwidth usage among flows, or enforce any particular scheme for establishing bandwidth usage relationships between flows. The application should be free to implement whatever adaptation policy is most appropriate in whatever manner is most appropriate.