Re: Historical question: Link layer flow control / silent discard

    > From: Detlef Bosau <[email protected]>

First, 'flow control' these days is taken to mean 'end-end' - i.e. the
original source not sending data faster than the ultimate destination can use
it. This has always been handled at the tranport layer - in the case of TCP,
by the TCP window. Rate control based on the ability of the _network_ to
carry traffic (which is what you seem to be asking about below) is now
usually called 'congestion control'.

I don't recall how carefully we differentiated between the two back then,
although I am quite sure we already understood the difference.

    > When I read the original catenet work by Cerf, the Catenet employed
    > link layer flow control.

I'm not sure that's quite correct: without checking the documents for myself,
I suspect they would have understood that if the source is connected to
network A (a fast network), and the next hop is network B (a slow network),
the link layer flow control on network B would be no use in slowing down the
host - since it's not connected to network B.

As I recall, we thought ICMP Source Quench would be the way congestion
control would be propogated back to the host.

    > To my understanding, this was abandoned when the ARPAnet turned into
    > the Internet (in 1981?). After this change, the link layer flow control
    > was replaced by a "silent discard" of packets which cannot be accepted for
    > delivery.
    > Is this correct?
    > What was the reason for this decision 

Source quench turned out not to work (for reasons I don't recall clearly any
more - Google will probably turn some things up). Possibly we just didn't
understand enough about congestion control at that early stage to make it
work 'well'.

I don't recall when we stopped trying to use it - I think it was a little
later than the cutover, actually.

We then ran without any congestion control at all for a while, and that
caused massive problems. Finally Van Jacobsen turned up and saved the day.
His approach turned out to only need packet drops as a congestion signal,
so SQ was not needed any more (and IIRC it has been deprecated).

    > have there been any alternative approaches?

Well, there have been some alternatives explored, I'm not sure how widely
any are used.

RED detects incipient congestion, and 'signals' it by dropping packets
(dropped packets being the typical 'congestion signal' post-Van). I classify
this as a different approach because although the _signal_ is the same,
the _triggering mechanism_ is different.

ECN is another approach. It's different from the early Source Quench stuff
in that i) I don't think it waits until queues are full (as SQ did), and
it doesn't return a separate packet to the source.

This is all from (dim) memory. Google will probably turn up more.

	Noel