40 Years of the Digest ... founded August 21, 1981
Copyright © 2021 E. William Horne. All Rights Reserved.

The Telecom Digest for Sat, 04 Jun 2022
Volume 41 : Issue 103 : "text" format

table of contents
Wireless Roundup (June 2022)
NYS AG: Verizon is dangerous to your health
Re: ISDN's days are numbered: What should you do?

Message-ID: <20220531191000.D14147ED@telecom2018.csail.mit.edu> Date: Tue, 31 May 2022 19:10:00 +0000 (UTC) From: Bill Horne <malQRMassimilation@gmail.com> Subject: Wireless Roundup (June 2022) by Wiley Rein Key Wireless Deadlines:
https://tinyurl.com/2p8bjf7e -- (Please remove QRM from my email address to write to me directly)
Message-ID: <Pine.NEB.4.64.2206030318160.5332@panix2.panix.com> Date: 3 Jun 2022 03:19:19 +0000 From: "danny burstein" <dannyb@panix.com> Subject: NYS AG: Verizon is dangerous to your health [twitter] NY AG James @NewYorkStateAG My office found that @Verizonfailed to maintain its cooling towers on buildings across New York City, causing the towers to spread Legionnaires' disease, a dangerous and lethal form of pneumonia. @Verizon will immediately act to correct its illegal operations. ======= rest of Twitter thread: https://twitter.com/NewYorkStateAG/status/1532515367041499156 Press release: https://ag.ny.gov/press-release/2022/attorney-general-james-reaches-agreement-verizon-prevent-legionnaires-disease _____________________________________________________ Knowledge may be power, but communications is the key dannyb@panix.com [to foil spammers, my address has been double rot-13 encoded]
Message-ID: <t73ht9$21c3$1@usenet.csail.mit.edu> Date: 30 May 2022 22:53:29 -0000 From: "Garrett Wollman" <wollman@bimajority.org> Subject: Re: ISDN's days are numbered: What should you do? In article <20220529205126.GA30139@telecom.csail.mit.edu>, Bill Horne <malassQRMimilation@gmail.com> 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
Opinions not shared by
my employers.
"Act to avoid constraining the future; if you can,
act to remove constraint from the future. This is
a thing you can do, are able to do, to do together."
- Graydon Saunders, A Succession of Bad Days (2015)

End of telecom Digest Sat, 04 Jun 2022

Helpful Links
Telecom Digest Archives The Telecom Digest FAQ