From: wollman@bimajority.org   
      
   In article <20220529205126.GA30139@telecom.csail.mit.edu>,   
   Bill Horne   wrote:   
      
   >Why would the bells hate the Internet? To be sure, their business   
   >model was built around central offices which each served a rate   
   >center, but how could they have predicted and/or anticipated the   
   >development of VoIP?   
      
   Voice over IP -- indeed, *multiparty* voice over IP -- was already a   
   thing by the early 1990s, before most people had Internet access at   
   all.  The problem, as it was then conceived, was that there wasn't a   
   whole lot of bandwidth available on inter-network links.  The NSFnet   
   had just upgraded from 56k to T-1 to T-3 over a very short period, and   
   while people thought that a whole 45 Mbit/s was an *enormous* amount   
   of bandwidth, that was still only 690 simultaneous point-to-point   
   voice connections (assuming the routing actually worked out).   
   Videoconferences were even more bandwidth-intensive.   
      
   The folks I worked for in my first job out of college had a research   
   program called "ISIP" -- "Integrated services Internet Protocol" --   
   that was trying to figure out how to fix that, by providing both   
   aggregate service guarantees and individual, per-flow resource   
   reservations to the Internet architecture, and by translating those   
   service requests into something that could be provided by the actual   
   lower-layer network technologies.  That involved quite a bit of   
   standardizing service definitions, so that you could programmatically   
   give a service request to a network provider and they could tell you   
   yes-or-no whether they could service the request and how much it would   
   cost.  (This was what they hired me to work on, although it's largely   
   not what I actually ended up doing.)   
      
   Per-flow resource reservations over a public network turned out ot be   
   an intractable problem, for reasons that were part technical and part   
   economic.  (The PSTN was able to make it work by effectively only   
   providing one flavor of service, constant-bit-rate switched circuits.)   
   The economic reason, which was obvious even in the late 1990s, was   
   that (unlike the cooperative ARPANET and NSFnet, which were funded by   
   a single body for a unitary purpose), the commercial Internet   
   consisted of many mutually distrustful parties whose economic   
   interests were adversarial to one another.  (By 2000 there were big   
   controversies about some large providers using their market power to   
   impose a settlements regime on smaller carriers, when in the early   
   days, providers exchanged traffic over neutral, settlement-free   
   exchange points.)  In order to implement anything like resource   
   reservations, or even differentiated services, over the public   
   Internet, you needed interdomain capacity reservations, and that   
   wasn't in any provider's interest to implement at a cost customers   
   were willing to pay.   
      
   What really killed this line of R&D, however, was the dot-com bubble   
   of the late 1990s.  Suddenly, the newly commercialized Internet was   
   *awash* in bandwidth, as everyone who had the VC money to burn   
   invested in burying dark fiber in every right-of-way imaginable.   
   There was no need to worry about resource scarcity, because if   
   bandwidth was a problem, it was just a matter of swapping out the   
   transceivers and suddenly you had double, triple, even ten times the   
   bandwidth as before.  Resource reservation is something you need   
   contol latency when you're trying to maximize utilization of a limited   
   resource;[1] it doesn't help you if the resource is so cheap that you   
   can afford to run at 10% utilization all the time.   
      
   High-end router vendors still support RSVP (the resource reservation   
   protocol) and differentiated services for enterprise customers who   
   require them, and I expect in cable ISP networks supporting voice they   
   probably do get some internal use.  But we've all been Zooming for the   
   past two years and nobody's home wireless router supports them; we've   
   been streaming Netflix for more than a decade.  it's much easier and   
   cheaper for the endpoint software to adapt to the available bandwidth   
   than to set up DiffServ (never mind RSVP) at every customer router in   
   the world.   
      
   -GAWollman   
      
   [1] There is a well-known result in queueing theory that summarizes   
   like this: if you have a serialized resource of fixed capacity and a   
   queue in front of it, and if arrivals are random and independent, then   
   the length of the queue will grow without bound if the mean arrival   
   rate of requests exceeds about 85% of the capacity of the resource.   
   Of course real routers don't have infinite queues, they drop traffic,   
   but the latency can still be enough to wreck isochronous streams like   
   voice.   
   --   
   Garrett A. Wollman    | "Act to avoid constraining the future; if you can,   
   wollman@bimajority.org| act to remove constraint from the future.  This is   
   Opinions not shared by| a thing you can do, are able to do, to do together."   
   my employers.         | - Graydon Saunders, _A Succession of Bad Days_ (2015)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)