[e2e] Why was hop by hop flow control eventually abandonded?
ggm at apnic.net
Wed Jul 17 19:09:08 PDT 2013
There is something slightly awry for me seeing a bunch of people discuss
this like we're history of science students reviewing the royal society in
1688. Did I drop into an alternative universe?
Donald Davies aside, the players aren't all "dropped off the twig" yet. I
personally think their input has some primacy for me in the "why" side of
things, looking backwards. Maybe I'm missing the posts which say "I thought
that..." or "I decided that..."
Speaking for myself, as a aficionado of history of science, The post-hoc
rationalisations over why things happen often don't really reflect what was
going on at the time. People say "because of <blah>" but it isn't always
that simple. Sometimes you're just playing and your idea gets traction.
Sometimes you're exploring and you luck into something and it becomes
bigger than you thought. (mostly, I think I find myself down rat holes
which are irrelevant to the mainstream. Like my time coding ISO Transport
Classes 0-3 and misunderstanding that Transport Class 4 was TCP by another
I think that hbh happens right now. As Jon said, its on aggregates. But it
undoubtedly (oh, don't you love it when people make assertions which invite
the 'hang on, I doubt it' response.. so this is in my opinion..) informs
e2e by the outcomes on delay and drop.
Two systems operating on the same outcome fully decoupled invites
interactions which are chaotic. They might couple, or they might not. For
other unrelated reasons I found myself reviewing the TCP over X.25 back
history and a purdue  study noted that a 2 packet window in X.25 SVC and
PVC had a really bad effect on TCP. As did establishment cost on e2e delay
for those crucial first few packets. If you pace your behaviour based on
what happens at the start, this intermixing of dumb and smart can play bad.
On Thu, Jul 18, 2013 at 8:10 AM, Michael Welzl <michawe at ifi.uio.no> wrote:
> On Jul 17, 2013, at 11:16 PM, dpreed at reed.com wrote:
> > I would dispute underutilization being a problem. Most engineers
> confronted with an extremely bursty load (where the burstiness must be
> supported to get the kind of interaction responses desired - i.e. very low
> latency on complex web requests, etc.) would understand and *accept* the
> need for the network to be *on the average* very lightly loaded.
> > That is, even on the creaky old Bell System digital phone network, the
> actual capacity was over provisioned by a large factor - a factor of 10 or
> so - because of *Mother's Day* phenomena.
> "even on" => but this was connection oriented. "especially on" seems more
> likely to me. Mother's Day phenomena won't be so bad when things are more
> dynamic, that's the whole point. FWIW you could fill a net with LEDBAT-like
> traffic all the time… this might not be "green", but it won't cause a
> problem on Mother's Day.
> > If you aim for full utilization, even if you are a government sanctioned
> *monopoly*, you will serve your customers badly if you try to fill up your
> entire fixed capacity to > 50% on the average.
> > Of course, in the minds of academics, this is intolerable! But
> academics rarely bother to think about the real world of engineering,
> preferring to invent problems (like using all available capacity *on the
> average*) that give them well-formed mathematical optimization problems.
> Yes, I said that I consider underutilization a problem, but I didn't say
> what you say here.
> > Are you serving your students well? Are you serving your research
> community well? Not bloody likely.
> I beg to differ :-) Academics should be forward-looking, no?
More information about the end2end-interest