[e2e] Why was hop by hop flow control eventually abandonded?

[Noel Chiappa]

    > From: Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk>

    > so i think the design decision to throw out all hop by hop flow control
    > was probably an error 

I'm not sure I agree with that.. but i) I need to ponder for a while, and ii)
I want to make sure I understand what you mean by 'hop by hop flow control',
because I'm not sure we're all using the same meaning.


Everyone seems to be assuming there are two choices: hop-by-hop and end-end.
However, depending on _exactly what one means by those terms_, I think there
may be four, or so, choices on how to signal congestion.

First, end-end - which I assume means 'the destination tells the source
things that the source uses to do rate control'. One would tend to assume
that this is the oldest meaning of the TCP window - i.e. information about
the amount of buffering available at the destination. But does this also
include information about the state of the network?/

Next, at the other end of the spectrum, hop-by-hop. When _I_ hear this term,
it means to me something like X.25/X.75 congestion control: e.g. you have a
channel across 5 networks A,B..E, and if D starts to congest, it tells that
to C, and then C tells that to B, and eventually word gets back to the source
host.

Then, there is something in the middle, which I will call 'direct', which is
'the place which is experiencing congestion tells the source about that
congestion directly'. There are two sub-flavours of this: 'direct-direct', in
which the congestion location does communicate directly with the source
(think ICMP Source Quench).

The second is 'piggy-backed direct', in which, to avoid sending a separate
control packet, the information is added to packets heading to the
destination, where it is turned around and sent back to the source. (I guess
a better short term for this is 'echoed-direct'. Now, perhaps people are
including that one in 'end-end' when they think of 'only two', but I think
it's clear that in some sense it's fundamentally different from 'true'
end-end: the _source_ of the congestion indication is _in the network_, not
at the end - and the only reason it comes from the destination host is that
that's the most efficient way to get it back.


With that taxonomy in hand, we can first examine the history of congestion
control in the Internet.

Initially, we tried to use a mixture of end-end (for buffering in the
destination), and direct-direct (ICMP SQ). The latter part didn't work so
well (for reasons I suspect we still don't understand very well - and I think
it might work better in today's networks than it did across the ARPANet - I
would _love_ to see someone experiment with it, and try and see if it could
in fact work).

So then we moved onto pure end-end. That didn't work so well either. So then
Van added some echoed-direct, using _only the information already available
to him_ - i.e. information about dropped packets (the simplest congestion
signal).

Then later on, we started tinkering with more sophisticated echoed-direct,
first with ECN, and then with XCP (which turns out, now that I refresh my
memory, to also be in this class - it's just that the information sent back
is much richer, semantically, than just 'yes/no').


And now back to your original point - leaving out hop-by-hop was bad. If you
really meant HbH as defined above, I don't agree. The reason is that I
suspect it's slower (not to mention more complex) than simply sending a
signal straight back to the original source: either direct-direct, or
echoed-direct. I suspect that even the latter is faster, in real time, than
having network D congest, and tell network C about it, etc, etc.

Reaction?

	Noel