[e2e] Open the floodgate

[Theo Pagtzis]

   Yet, IP
> 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 
cavity either

   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 
whatever reason)
      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 
a collapse..

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

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


  So, as
> 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')


  It didn't
> 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."  
> 
-- 
theo
Nets & Mobile Systems Group
UCL-CS