[e2e] Historical question: Link layer flow control / silent discard

[John Day]

At 1:48 PM -0400 5/24/13, Noel Chiappa wrote:
>     > From: Detlef Bosau <detlef.bosau at web.de>
>
>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 am sorry Noel, but I have to disagree at least with the attitude. 
Flow control can occur at any layer and pretty much has.  The fact 
that it may not currently doesn't mean it never will.  This is 
precisely how the craft mentality that permeates this field got 
started.  One of the things I impress on my students (with examples) 
is that old solutions never go away, they return, often with somewhat 
different parameters.  At today's data rates, it is unlikely to see 
flow control at the data link layer, or elsewhere in between, but who 
knows!

And why I define flow control as feedback co-located with the 
resource being controlled and congestion control as feedback not 
co-located with the resource and try to stay away from the more 
vocational definitions.

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

Yes, it was quite clear at the time that flow control at the data 
link layer had a different purpose than flow control at the Transport 
layer.  (I should probably qualify that.  At least, it was quite 
clear to some people.  I have had a few surprises of late of things 
that I thought were quite clear early on and seem to have been 
totally missed.)

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

At the very least all of the networks at the time (ARPANET, NPL, 
CYCLADES, etc.) used a data link protocol that did retransmission and 
flow control.  By the end of the 70s, it was probably disappearing. 
IEN#1 (1977) conjectures that ingress flow control at gateways is 
probably going to be important.  By this time, quite a lot of 
research had been done on congestion control in these kinds of 
networks.

Take care,
John

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