[e2e] common congestion controller for TCP connections

[Hari Balakrishnan]

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

No, the CM API calls are not syscalls when used by TCP.  They can be (and are) 
made by the TCP.

> > 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

Joe,

When we wrote our TCP (under Linux; non-BSD!) that decoupled congestion control 
from it and only left the loss recovery in it, the end result was a 
substantially simpler, easier-to-understand TCP and stack.  Modularity helps in 
this case quite a bit.

When you're dealing with something as complex as a TCP, I would be wary of 
schemes that claim to be simpler because they only "play with TCB variables".  
As we all know, even a "small" change in a TCP can have unintended, adverse 
interactions and consequences.

Hari