[e2e] common congestion controller for TCP connections
hari at nms.lcs.mit.edu
Tue Oct 29 11:07:17 PST 2002
> To add to the discussion,
> IMO, the primary difference between CM and TCB-sharing approaches is
> what happens with a single packet.
> in CM, a single congestion control system processes every packet
> in TCBI, conventional per-connection congestion control processes each
> In both cases, information can be shared among a set of sequential or
> concurrent connections, and in both cases the aggregation and timescale
> (per packet, at connection start, etc.) of sharing is determined by
> policy, not the architecture. CM allows non-TCP applications to benefit
> from TCP-'like' congestion control; TCBI is simpler to use from the
I don't believe the second part of the last sentence above. When TCP is
implemented over CM and shares congestion information between a group of (TCP)
flows all in the same macroflow (terminology from RFC 3124), then the
application does not even see it. CM applications can benefit from the CM API
if they choose to, or ignore it if they don't. TCP can be implemented over CM
and apps are oblivious to it.
I don't see why "TCBI is simpler to use..."
> E.g., E-TCP is TCB-sharing where a policy of "connections with the same
> src/dst should be aggregated as if a single connection". There are, as
> you point out, other policies. TCBI includes a suggestion that is
> similar to that of SPAND, that some congestion information can be shared
> among endpoints on a LAN, FYI (see "Implications").
More information about the end2end-interest