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

Jon Crowcroft Jon.Crowcroft at cl.cam.ac.uk
Wed Jul 17 03:07:34 PDT 2013

I think the notion of "smearing out traffic" over multiple alternate
routes (ie. resource pooling) at a slightly faster timescale than
traffic engineering, is actually part of Davies' original vision for
packet switching (see isarythmic flow control)....

for me, since it isn't end2end, it is sort of hop by hop....but it
isn't "per e2e flow" either

I don't see a problem with it - in fact re-ecn/congestion exposure is
surely a new variant on that old old old idea...?

In missive <1D9ADEAB-16E0-444A-8C97-3D1262F350E7 at ifi.uio.no>, Michael Welzl typ

 >>i agree like i haven't agreed to anything in a long time! in fact i agree with every single word jon wrote here
 >>Sent from my iPhone
 >>On 17. juli 2013, at 10:36, Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> wrote:
 >>> so most systems in the world do hop by hop as well as end to end
 >>> e.g. 
 >>> transportation systems  (traffic lights, stacks of planes, semaphores to
 >>> control trains entry/exit from track sections etc etc)
 >>> power systems (elec ant gas)
 >>> water systems (valves etc)
 >>> eco-systems (food chains/feast/famine etc)
 >>> political systems (you switch from feudal to democract, btut you still
 >>> have periodic elections - you switch from city states to countries,
 >>> but still have border and immigration/emigration controls...:)
 >>> so why do we think comms should be different?
 >>> in fact, I suggest we do some flow control inside nets - its called
 >>> traffic engineering and operates on aggregates - when we do 
 >>> multipath routing, we also select a modest number of routes (obviously
 >>> more than 1 but a lot less than actually would give connectivity or
 >>> even some additional capacity)....
 >>> so i think the design decision to throw out all hop by hop flow
 >>> control was probably an error (not a disastrous one: as many people
 >>> have pointed out, it simplified early router design a lot to be
 >>> completely stateless - but you don't need to keep per-5-tuple based
 >>> e2e state to do hop by hop flow control if its on aggregates, right?)
 >>> In missive <1374014873.23736.140661256474709.49B0CF90 at webmail.messagingengine.c
 >>> om>, Mark Handley typed:
 >>>>> It's before my time, but I'd always assumed it was also influenced by
 >>>>> the NVP work, which would not have wanted hop-by-hop flow control.
 >>>>> Mark
 >>>>> On Tue, Jul 16, 2013, at 02:24 PM, Bob Braden wrote:
 >>>>>> I believe that hop-by-hop flow control only works with per-flow state in 
 >>>>>> the routers (see X.25 for example). Once the decision was made that the 
 >>>>>> routers should be stateless, end-to-end flow control was the only 
 >>>>>> option. That is what the end-to-end principle is all about.
 >>>>>> Bob Braden
 >>> cheers
 >>>   jon



More information about the end2end-interest mailing list