[e2e] Open the floodgate
t.pagtzis at cs.ucl.ac.uk
Fri Apr 23 02:44:26 PDT 2004
> provides a simple way of doing exactly this. As I implied before, ECN is a
> late, partial admission that a problem has long existed and needs attention.
> None of us waits as many decades to get a cavity filled -- at least I hope
> none do.
IMHO it is all a matter of priorities what needs fixing..it all depends
if one goes either 'preventive' or 'corrective'. To keep up with the
medical examples..did you ever take medicine in the fear that you MAY
get ill? don't think so...But as soon as you started feeling bad
(actually as soon as your threshold of tolerance -
biological/patience/other - exceeded some value) then you MUST fix it.
(The 'SHOULD lies somewhere in between in the threshold ranges')
The reason is that sometimes one is not _aware_ of the cavity until the
1) declares its presence with some signs as a potential (maybe
future) problem (foresight hints - 'fix me or later I will bug you')
2) requires attention
3) requires IMMEDIATE attention
How would you rate the possibility of a congestion collapse as opposed
to the possibility of a need for notification on congestion (hints)? I
guess one should have a few things to consider:
a) could one afford notification signals at the time (1988?) (for
b) did one _want_ notification signals ?
c) did one _think_ of notification signals (it can happen)?
Also it should be noted that only as an aftermath (AFTER observing the
'evolution' of the problem as I call it) one could have decided that it
is better to start worrying about notifying _before_ starting to address
> And on: "..take something out of the environment..." -- how long do we wait to
> do something? We floundered for years on something as basic as addressing.
> As others have said, the IETF wins the slowness race with other networking
> bodies. And, note that I'm not "denigrating" TCP, I'm raising issues that, if
> dealt with, would prolong its overall life and improve its effectiveness.
> Others have raised many of the same issues over the years and been rebuffed.
> Rebuffing is what bureaucracies do, so that's the criticism. TCP is
> inanimate. Only people can resist changes in it.
eeemm here a familiar pattern crops in mind. Linux distros is an
engineering effort that continuously reshapes the OS entity towards
'prolonging life and improving effectiveness' as you quite rightly put
it. Now the next question is...if change is continuous (the rate of
continuity is relative to size of the entity) would you TRUST that
entity of mission critical (the definition of criticality changes for
whoever uses it - so we have to go with the lowest common denominator)
That is to say...if one constantly evolves TCP although long-term it
will be ok can you afford it NOW??? I remind that the Internet as we
know it now is not a research effort anymore. It is a commercial venture
and is about to become a public utility. Can you afford to be without
water on a non-deterministic basis even if one told you that 'the pipes
we are building will prolong usage life and improve effectiveness, given
that we have to change ALL the pipes in the network (i.e. TCP
> I've simply said, the initial congestion-control kludge may have been
> needed, but so was continued development of more comprehensive congestion
> management that even nodes running, say, UDP could benefit from.
totally agree with this as I feel it from the WLAN perspective. Could it
be that the politics of vendors driving some percentage of the force of
the IETF cannot agree on the need to get together (not compete against
each other) and give momentum into an effort (as per your suggestion)
such that, its output will indeed get to be phased in??? A quick
example: see where IPv6 has been and see the tremendous effort that
companies/universities/the pope of Rome is putting into convincing the
world to use it! Do you dare (if you were the IETF) doing the same with
a comprehensive congestion management mechanism (say TCPpro)? It would
be a mission in life in convincing the clueless (but enterpreneurial)
spirit of the 'user' out there..
now the funny thing is that as soon as the cavity needs immediate
attention..you have to fix it or lose it :)
in a nutshell...TRANSITION mechanisms :)))
and presto a new discipline.... TRANSITION engineering...
(with the motto..'habit is a bad thing')
> happen and folks who were there know about the great biases oddly set up
> against doing things to involve the Network layer more effectively.
> And, there's more than "only one more layer down there", which when you look
> into the various types of Datalink devices and systems around also points up
> instances of flow management that again, IP was never allowed to be made aware
> of. Even use of "the internetwork layer" as the only layer below TCP itself
> is a throwback to how the IP family was designed -- to talk to other I/O
> processors (IMPs...), not to any resident drivers for physical media. There
> was no concept of addressing physical interfaces, LANs, etc. Only other
> Network-layer devices were conceived of, and not many at that, which is why IP
> addresses were so small. An interesting thing is that during the '80s and
> '90s, when corporate networks could address 80 bits worth of Network-layer
> systems, IP was floundering on its inadequate base and complex
> addressing schemes. Now, of course, the ultimate addressing kludge (NAT) has
> even forestalled IPv6 in common use (which may even be a good thing :)
> As far as: "And trust me, a network in congestive collapse is so much worse
> than the effects of treating error packets as congested packets, that the
> latter just didn't seem very important. If you had to live with congestive
> collapse you'd appreciate that."
Nets & Mobile Systems Group
More information about the end2end-interest