[e2e] common congestion controller for TCP connections

[Joe Touch]

Hari Balakrishnan wrote:
>>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.

How does the macroflow get setup? Last time I saw it it required system 
calls. If you're assuming that TCP is just rewritten to use the CM 
rather than direct output, then they should be identical from the 
application.

> I don't see why "TCBI is simpler to use..."

Perhaps equivalent from the application's perspective, if nonstandard 
syscalls can be avoided.

However, still simpler to implement things that play with TCB variables. 
You can start with a BSD (or even, gasp, non BSD) stack and just 
manipulate the TCB variables. There's a lot less additional mechanism to 
deal with, either to port, or to remove as an artifact of an experiment.

Joe