[e2e] Skype and congestion collapse.

[Cannara]

Exactly the right question, Clark.  But I'll differ with you on the blanket
plaudits to Inet or TCP design.  We all know the design of the network layer
was inadequate and knew that years in advance of address inadequacy.  Doing
"just enough" isn't something that can be foreseen either -- how do you know
it's "just" enough?  

On the PSTN, which has such a clean record for access control, sharing,
reliability, etc. (and was the physical basis for the Internet) the Inet comes
not even close, for the very reason you mention "just enough".

So, yes, when will the Inet be properly engineered so kludges like a transport
doing what the network should do are gone?  Of course, I and other consultants
can't complain -- just got paid a couple hundred an hour today to tell someone
that NAT boxes don't always let FTP PORT commands through poroperly!  Hmmm,
now why did we need NAT?  Oh yes, "just enough" (for 1980 :).

Alex

Clark Gaylord wrote:
> 
> Alex Cannara wrote:
> 
> > Syed, the misconception is that apps are to manage network resources.
> > That's not how more robust systems, like the established telco and
> > private network systems work.  Systems must protect themselves, even a
> > car's gearbox, from external abuse.  The Internet is only different in
> > that attention wasn't paid to doing that in its design.
> 
> But that doesn't mean that we can't pay more attention to it now.
> Gearboxes didn't protect themselves originally either, but synchromesh
> and fluid drive have done a lot to address that.  The advances in
> computing are due to algorithms, and in recent years that has been
> parallel algorithms.  That's what TCP is: a distributed, parallel
> algorithm that does a reasonable job of equitably sharing limited
> resources.  But you are correct that our network systems can do more to
> enforce fairness and compliance at some level.
> 
> By protecting TCP traffic from non-TCP-friendly traffic, by ensuring
> that TCP plays by the rules, by judiciously and scalably employing
> policing and differential queueing -- we can build a much better
> system.  But what makes the Internet a superior *engineering* solution
> is that it doesn't try to over-specify everything.  "Do just enough" is
> what makes this work, and it isn't due to laziness: it is due to the
> inherently superior scalability of this approach.  We don't need to
> debate whether the Internet is a superior solution to the PSTN; reality
> has already proven that.  What is left is for those of us who wistfully
> harken to when TDM was king and everyone had a 3270 to understand that
> we need to crack our bell-shaped heads open and get up to date.  Poisson
> and Erlang don't apply anymore, but doesn't mean we can't model (or that
> we can't extend them in interesting ways, btw).  Call admission doesn't
> apply anymore, but that doesn't mean we have to drop all packets equally.
> 
> "What do we need to do to make the Internet better?" is the question we
> need to be asking.
> 
> --ckg