[e2e] common congestion controller for TCP connections
hari at nms.lcs.mit.edu
Tue Oct 29 11:23:24 PST 2002
> >>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
> > 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
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.
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.
More information about the end2end-interest