[e2e] common congestion controller for TCP connections

[Hari Balakrishnan]

> 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 
> packet
> 
> 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 
> application.

Joe,

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").
> 
> Joe

Hari