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