[e2e] Open the floodgate

[Noel Chiappa]

    > From: Cannara <cannara at attglobal.net>

    > TCP was modified to provide network congestion control some years ago u
    > -- something that is clearly a violation of layering responsibility

You say this very glibly, as if doing something different were trivial and
obvious. I don't think it's quite so trivial or obvious (especially not in
hindsight), however.

If don't want the transport layer to do congestion control, what layer do you
want to do it? There's only one more layer down there - the internetwork
layer. Adding congestion control there would greatly increase the complexity
of the internetwork layer, and all the devices that implement it - including
the routers.

If you say "OK, so there should be a shim layer in the middle", then you run
into the issue that you've now added another layer, with attendant
implementation complexity and overhead. The natural response would be to fold
the functionality into the transport layer, to get rid of the structuring
overhead of a separate layer.

Sure, with hindsight, another layer in there might have been good when the
network got to be really large, and much faster. (We could have
location/identity binding in there too, perhaps.) However, all sorts of
things are obvious in hindsight, and would *now* be good to have, now that
the network is larger, weren't so obvious (or obviously economical in the
long run) back then.

I can tell you exactly how the transport layer wound up doing *network*
congestion control - it's because it was already doing *host* congestion
control, specifically via the window field. The transport layer did host
congestion control for a very simple reason: it was the layer that knew how
much buffering was available - because it managed the buffers where data was
held until it could be ACK'd. (Surely a transport responsibility, no?) Once it
was doing one kind of congestion control, adding the other was just the most
straightforward thing to do.


    > a protocol that believes it needs to slow down whenever it sees a
    > packet loss.

Look, we all have known for some time that i) TCP can't currently distinguish
between error loss and congestion loss, and ii) slowing down for an error loss
is a mistake.  (In fact, I'm losing horribly these days because my mail is
kept on a host which is on a network which is losing packets, so I am
personally aware of this issue.) We're not cretins. You don't need to keep
repeating it.

    > There are various causes of loss, which was a fact even known in the
    > '80s when TCP was kludged, so why ignore them and incorrectly lump them
    > with congestion?

Because when the network fell into congestive collapse - which we *were
actually seeing* back before TCP had congestion control, losses due to
congestion far outnumbered the losses due to error, so the latter could
safely be ignored.

And trust me, a network in congestive collapse is so much worse than the
effects of treating error packets as congested packets, that the latter just
didn't seem very important. If you had to live with congestive collapse you'd
appreciate that.

	Noel