[ih] ARPANET pioneer Jack Haverty says the internet was never finished

[touch at strayalpha.com]

Hi, Jack,

> On 3/2/22 08:53, touch--- via Internet-history wrote:
>>> On Mar 2, 2022, at 8:22 AM, Noel Chiappa via Internet-history <internet-history at elists.isoc.org> wrote:
>>> 
>>>> On Tue, Mar 1, 2022 at 8:46 PM Jack Haverty wrote:
>>>> One that I used in the talk was TOS, i.e., how should routers (and TCPs)
>>>> treat datagrams differently depending on their TOS values.
>>> I actually don't think that's that important any more (or multicast either).
>>> TOS is only realy important in a network with resource limitations, or very
>>> different service levels. We don't have those any more - those limitations
>>> have just been engineered away.
>> Not all networks can be over-provisioned; DSCPs and traffic engineering are alive and well.
...
> Absolutely.  The audience for my talk was technical-savvy people who are involved in building and/or operating the pieces of the Internet in places where fiber hasn't carpeted the area yet - places like Bangladesh et al, where they do have to pay attention to traffic engineering.

Underserved areas are everywhere - my car, my phone, apartments in buildings that are hard to retrofit, and (especially) people in places that don’t warrant the shared cost of fiber, e.g.:
https://vividmaps.com/us-population-density/ <https://vividmaps.com/us-population-density/>

There are lots of places where there are too few people per square mile, but there ARE still people.

> But even so, I included the anecdote of my friend and his recent attempt at a "gaming" experience (actually a remote-desktop kind of situation) over the path between LA and Reno, NV.
...
> That same behavior was reported by people like Steve Casner, Jim Forgie, et al as they tried to do real-time interactive voice over the early 1980s Internet. '

Same behavior might not be from the same cause.

New causes include bufferbloat, poorly provisioned access networks (miscalculated uplink vs. downlink capacity), etc. Four decades later, RAM is cheap and nearly everyone has a streaming video source, but those benefits came with problems that packet prioritization alone cannot solve.
...

> Placeholder mechanisms were put in place.  TOS bits were a way for a host to indicate what kind of service was required for each datagram, after someone figured out what different services routers could provide.  
...
> But from a user's perspective, mechanisms and algorithms aren't useful until they're present and operating in all the equipment that's involved in whatever the user is trying to do.   Are they there?  Can't tell.  The talking heads on TV still pixelate.  My friend can't play his game.

TOS became DSCP and ECN; both are enabled by default in many OSes. Granted, they’re not always ubiquitous in routers, but that could just be a tragedy-of-the-commons pricing issue; nobody wants to individually pay for something that has only group benefit. 

But again, the behavior you saw may have a root cause unrelated to packet priority.

...
> In the earliest ARPANET days, the NOC used to keep track of end-to-end delay, with a target of keeping it under 250 milliseconds (IIRC).  Most users then interacted with their remote computers at typewriter terminals, and became unhappy if their keystrokes didn't echo back at least that quickly.
> 
> Today's Internet, admittedly from my anecdotal experience, seems to think 30 seconds is perfectly acceptable as long as all the datagrams get there eventually.

That’s almost definitely bufferbloat, FWIW.

Joe