On Sun, May 22, 2022 at 12:11:50PM -0400, Fred Goldstein wrote:

On 5/21/2022 12:36 PM, Bill Horne wrote:

On 5/19/2022 9:05, Bill Horne wrote:

I was talking to an old friend yesterday, and he told me that he's
been working from home for a while now, and the conversation turned to >>>ISDN phone service, which I recommend to anyone who can still obtain >>>it.

1. Which states still have tariffs for ISDN BRI lines?

...

ISDN Basic Rate Interface (BRI) is generally no longer available in
the US. Verizon and I think ATT long ago gave formal notice of
discontinuance or grandfathering. Maybe Qwest, pre-Century, didn't
bother, so it may still be on the books there. But few know how to
provision it. Many of the switches that provided it (mainly 5ESS and
DMS-100 in the US) no longer are in service. It was useful, especially
for broadcasters doing remote feeds. It was better than a modem for
Internet access, and that's what killed it as it was coming out in the
early 1990s -- the Bells hated the Internet, which broke their
locality-based business model, and while they couldn't attack modem
users per se, they could at least attack the most obvious Internet
user group, non-Centrex ISDN BRI users. Bell Atlantic l/k/a Verizon
was also fanatical in those days about selling Centrex, and saw ISDN
BRI as a tool for Centrex feature phones, but that was about it. That business has faded out too.

I don't often disagree with Fred on issues like ISDN, but I'm going to
advance a different theory: I had a chance to test an ISDN line at my
home near Boston, back around 1994 or so, and I was /very/ surprised to
find that getting a 64Kbps connection on either of the "Bearer"
channels was very difficult.

It turned out that the only solution was to redial several times, and
sooner or later I'd get a 64Kbps connection. After 15 or 20 minutes of
dialing and redialing, I might end up with two 64Kbps "Bearer"
connections to The Well, an ISP which served ISDN customers, and I
could bind them together to obtain a 128 Kbps Internet connection.

When I investigated, I quickly found out that almost all of the
T-Carrier systems connecting the central office to its Tandems were
not equipped for "8 bit clean" connections. In other words, the
connections from the CO to Tandem offices were designed for the
original T-Carrier "robbed bit" signalling paradigm, and were not
capable of delivering 64Kbps data connections.

I think Verizon - and probably the other Baby Bells - wanted to avoid
the expense of retraining a unionized workforce to make use of the
8-bit-clean fiber-optic channels just being introduced at the
time. The company would have had to retrain not only the "CO"
technicians, but also the provisioning specialists responsible for
specifying the number and type of trunks for each CO to use for each
service. Even though ISDN data calls were billed per-minute, the
accountants most likely projected more cost than revenue.

Bill

--
Bill Horne
(Please remove QRM from my email address if you write to me directly)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/21/2022 12:36 PM, Bill Horne wrote:

On 5/19/2022 9:05, Bill Horne wrote:

I was talking to an old friend yesterday, and he told me that he's
been working from home for a while now, and the conversation turned to
ISDN phone service, which I recommend to anyone who can still obtain
it.

1. Which states still have tariffs for ISDN BRI lines?

...

ISDN Basic Rate Interface (BRI) is generally no longer available in
the US. Verizon and I think ATT long ago gave formal notice of
discontinuance or grandfathering. Maybe Qwest, pre-Century, didn't
bother, so it may still be on the books there. But few know how to
provision it. Many of the switches that provided it (mainly 5ESS and
DMS-100 in the US) no longer are in service. It was useful, especially
for broadcasters doing remote feeds. It was better than a modem for
Internet access, and that's what killed it as it was coming out in the
early 1990s -- the Bells hated the Internet, which broke their
locality-based business model, and while they couldn't attack modem
users per se, they could at least attack the most obvious Internet
user group, non-Centrex ISDN BRI users. Bell Atlantic l/k/a Verizon
was also fanatical in those days about selling Centrex, and saw ISDN
BRI as a tool for Centrex feature phones, but that was about it. That
business has faded out too.

ISDN Primary Rate Interface (PRI), which runs over a DS-1 ("T1")
channel, is still out there, though again its number are in
decline. It is a very good trunk interface for PBX systems, and many
different 1995-2010 vintage switching systems support it, as it
handled the dial-up era's modem pools. But most newer systems use SIP
trunks instead. PRI has higher quality of service than SIP/RTP/IP, but
the industry has moved away from it, as the higher-volume IP services
usually have a lower price tag.

--
Fred R. Goldstein k1io fred "at" ionary.com
+1 617 795 2701

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For POTS, whether delivered over copper or ISDN, it appears that there is
an effort to move from circuit switched to packet switched (VoIP). Besides
the efficiency of packet switched (data compression and no bandwidth
allocated to silence), VoIP is not regulated as a common carrier under
title 2, as far as I know.

Harold
https://w6iwi.org

***** Moderator's Note *****

Harold,

You have an interesting website: I especially liked the link to the
Model 19 Teletype repair photos. I learned to type on a Model 19, at
the M.I.T. Radio Club, W1MX, back around 1968.

Bill Horne
Moderator

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/22/22 8:41 PM, Bill Horne wrote:

When I investigated, I quickly found out that almost all of the
T-Carrier systems connecting the central office to its Tandems were not equipped for "8 bit clean" connections. In other words, the connections
from the CO to Tandem offices were designed for the original T-Carrier "robbed bit" signalling paradigm, and were not capable of delivering
64Kbps data connections.

This seems to be directly related to the type of bearer channel /needed/
to support the type of call being placed.

E.g. /data/ was supposed to be 64 kbps / 8-bit clean from TA to TA all
the way through the network. Conversely, /voice/ and / or /audio/ calls
(terms are slightly different) could use 56 kbps or even analog trunks somewhere in the middle of the network.

My understanding is that 64 kbps / 8-bit clean calls are supposed to
refuse to establish over an impure intermediate transit between two
switches.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/22/2022 10:41 PM, Bill Horne wrote:

...

ISDN Basic Rate Interface (BRI) is generally no longer available in
the US. Verizon and I think ATT long ago gave formal notice of
discontinuance or grandfathering. Maybe Qwest, pre-Century, didn't
bother, so it may still be on the books there. But few know how to
provision it. Many of the switches that provided it (mainly 5ESS
and DMS-100 in the US) no longer are in service. It was useful,
especially for broadcasters doing remote feeds. It was better than
a modem for Internet access, and that's what killed it as it was
coming out in the early 1990s -- the Bells hated the Internet,
which broke their locality-based business model, and while they
couldn't attack modem users per se, they could at least attack the
most obvious Internet user group, non-Centrex ISDN BRI users. Bell
Atlantic l/k/a Verizon was also fanatical in those days about
selling Centrex, and saw ISDN BRI as a tool for Centrex feature
phones, but that was about it. That business has faded out too.

I don't often disagree with Fred on issues like ISDN, but I'm going to advance a different theory: I had a chance to test an ISDN line at my
home near Boston, back around 1994 or so, and I was /very/ surprised to
find that getting a 64Kbps connection on either of the "Bearer"
channels was very difficult.

It turned out that the only solution was to redial several times, and
sooner or later I'd get a 64Kbps connection. After 15 or 20 minutes of dialing and redialing, I might end up with two 64Kbps "Bearer"
connections to The Well, an ISP which served ISDN customers, and I
could bind them together to obtain a 128 Kbps Internet connection.

When I investigated, I quickly found out that almost all of the
T-Carrier systems connecting the central office to its Tandems were
not equipped for "8 bit clean" connections. In other words, the
connections from the CO to Tandem offices were designed for the
original T-Carrier "robbed bit" signalling paradigm, and were not
capable of delivering 64Kbps data connections.

I think Verizon - and probably the other Baby Bells - wanted to avoid
the expense of retraining a unionized workforce to make use of the 8-bit-clean fiber-optic channels just being introduced at the
time. The company would have had to retrain not only the "CO"
technicians, but also the provisioning specialists responsible for
specifying the number and type of trunks for each CO to use for each
service. Even though ISDN data calls were billed per-minute, the
accountants most likely projected more cost than revenue.

The 64-kbit data bearer service was, as you note, not widely
available. For it to work, both the transmission systems and the
switching systems needed to implement the B8ZS fix to the T1 carrier
system specification. And yes, NYNEX was full of old line cards that
only did the not-clean old AMI format. They had upgraded some of the
switches to have ISDN but didn't update the trunk network. Also, the
inbound ports needed ISDN PRI, which they were initially slow to roll
out. They treated ISDN data as "Switched 56", an older data service
that accommodated robbed-bit signaling. That was where their tariff
came from too, at 8c/minute for data calls.

There was a work-around, though. I always used "data over voice bearer
service" (DOVBS), wherein the network was told it was a voice call and
the terminal gear only used the clean 7 bits, for a 56k connection.
That not only worked well, but took advantage of the flat rate voice
calls on residential lines. Those calls could also terminate into a
modem pool that was not on ISDN PRI, just on the older robbed-bit T1
trunk service. When I was setting up DEC's ISDN trial circa 1993,
they actually told us to do that, as they had no other way to deliver
the calls.

--
Fred R. Goldstein k1io fred "at" ionary.com
+1 617 795 2701


***** Moderator's Note *****

For some reason, "DOSBS" (Data Over Speech Bearer Service) was a taboo
subject by 1994: the ISP's that supported ISDN connections all
pretended that they had never heard of it, and "bonding," even with 56
Kbps *DATA* calls, was likewise a mystery.

Bill Horne
Moderator

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Fred Goldstein" <invalid@see.sig.telecom-digest.org> writes:

The 64-kbit data bearer service was, as you note, not widely
available. For it to work, both the transmission systems and the
switching systems needed to implement the B8ZS fix to the T1 carrier
system specification.

As one who had to troubleshoot ISDN calls failing.
In my area (Minneapolis), I found 64k bearer calls went through more
than 98% of the time.

When those 2% failures came through, I would have to do the cycle
through the almost always CLEC's supportsystems, get them to trap the calls, and get them to figure out which trunk was marked as 8-bit clean, but
only could handle the 7-bit channels.

To me, it didn't seem like they were purposely not upgrading anything,
just that the 7-bit trunks weren't marked correctly in the switch
database, so that when 64k calls wanted to go through, the switch
incorrectly put them on a 7-bit trunk.

The fix almost always was for the CLEC techs to mark the trunk
properly in the switch database, and there were plenty of 8-bit clean
trunks to use, when they were marked correctly so 64k calls could
properly route through the COs.

Telecom Digest Moderator wrote:

For some reason, "DOSBS" (Data Over Speech Bearer Service) was a taboo >subject by 1994: the ISP's that supported ISDN connections all
pretended that they had never heard of it, and "bonding," even with 56
Kbps *DATA* calls, was likewise a mystery.

Since 64k calls went through at least 98% successful in this area, and
in this area, voice & data were all flat-rate billed, there wasn't any
point to do the data over speech calls. I don't remember having to
support anything special to make it happen, but then we didn't really
have any reason to have to do that in the first place, so I don't
remember what it took to happen.

We always did 128k bonded connections with no issues. No mystery here.
The biggest problem was the customer equipment. Most of it sucked
hard.

--
Doug McIntyre
doug@themcintyres.us

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, May 27, 2022 at 07:53:56PM -0000, Garrett Wollman wrote:

In article <O8SdnfjNCtEMEhP_nZ2dnUU7-LHNnZ2d@giganews.com>,
Doug McIntyre <merlyn@dork.geeks.org> wrote:

We always did 128k bonded connections with no issues. No mystery
here. The biggest problem was the customer equipment. Most of it
sucked hard.

In the early part of my career, I supported ISDN connections for staff
and faculty in my lab. This was before widespread cable ISP access
and overbuilding, but Bell Atlantic (as then was) had a special tariff
that allowed universities to get unmetered ISDN BRI lines installed at employees' homes. We used Ascend equipment to terminate a PRI in our building, which also supported model dial-up. Normally we'd use a
smaller Ascend box (smaller than my current cable modem!) on the
residential end, and we'd configure it to nail up both B channels 24x7
and give each user a subnet.

[snip]

I'm going to have to descend from whatever foothold I used to have on
Mount Olympus, and admit that I don't understand how you could "nail
up" two bearer channels without disabling the ISDN line's capability
to carry phone calls. Were the ISDN lines used only for data service,
or could the Bearer channels be divorced while a phone call was in
progress?

--
Bill Horne
(Remove QRM from my email address to write to me directly)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, May 22, 2022 at 12:11:50PM -0400, Fred Goldstein wrote:

On 5/19/2022 9:05, Bill Horne wrote:

I was talking to an old friend yesterday, and he told me that
he's been working from home for a while now, and the conversation
turned to > >>>ISDN phone service, which I recommend to anyone
who can still obtain it.

1. Which states still have tariffs for ISDN BRI lines?

ISDN Basic Rate Interface (BRI) is generally no longer available in the US. Verizon and I think ATT long ago gave formal notice of discontinuance or grandfathering. Maybe Qwest, pre-Century, didn't bother, so it may still be on the books there. But few know how to provision it. Many of the switches that provided it (mainly 5ESS and DMS-100 in the US) no longer are in service. It was useful, especially for broadcasters doing remote feeds. It was better than a modem for Internet access, and that's what killed it as it was coming out in the early 1990s -- the Bells hated the Internet, which broke their locality-based business model, and while they couldn't attack modem users per se, they could at least attack the most obvious Internet
user group, non-Centrex ISDN BRI users.

This is twice in one day that I've had to take a step downward from my
place on Mount Olympus, and I fear I might turn into Sisyphus if I
don't - pun intended - watch my step. ;-)

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? Did Mother Bell see /any/ data transmission
method as a threat? Why?

The Baby Bells knew that Cellular was coming, and I'd bet they knew it
would displace copper-served POTS within time we've had to see it
happen. Still, I just don't remember the leaders of the Baby Bells as
being such long-term thinkers. The Internet hasn't replaced their locality-based feeding trough: we still have and use phone numbers,
and even if a cell call has to be routed using VoIP and/or SIP trunks,
the savings in billing offered by "Free" long-distance would have more
than offset the cost of adapting to new trunking paradigms.

Bell Atlantic l/k/a Verizon was also fanatical in those days about
selling Centrex, and saw ISDN BRI as a tool for Centrex feature
phones, but that was about it. That business has faded out too.

I wonder why? What was so different between the business models of the
1990's and those of the 2020's that Centrex would no longer be a
cost-saver for firms which chose to use it? Granted, the Coronavirus
has caused a reexamination of work-at-home as a viable real-estate
strategy, but I think the /time/ spent on dialing, connecting, and
suffering with the shortcomings of cellular calls, like picket-fencing,
fading, disconnecting, and - last but far from least - being easily
tapped by anyone with an antenna ana a few items of listening
equipment.

ISDN Primary Rate Interface (PRI), which runs over a DS-1 ("T1") channel, is still out there, though again its number are in decline. It is a very good trunk interface for PBX systems, and many different 1995-2010 vintage switching systems support it, as it handled the dial-up era's modem pools. But most newer systems use SIP trunks instead. PRI has higher quality of service than SIP/RTP/IP, but the industry has moved away from it, as the higher-volume IP services usually have a lower price tag.

I'm afraid comparing IP-based telephony to ISDN PRI links is the
ultimate race-to-the-bottom in voice communicaiton. As far as I can
tell, the only thing that makes SIP or VoIP or /any/ Internet-based
real-time service - don't forget streaming video - viable is a surplus
of bandwidth which will, inevitably, decline as paid-prioritization
methods and equpment take hold.

Bill, who is feeling old and out-of-step.

--
Bill Horne
(Please remove QRM from my email address in order to write to me directly)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/29/22 2:51 PM, Bill Horne wrote:

Why would the bells hate the Internet?

I don't /know/ why. But I have a few speculations:

- Not Invented Here (bells)
- Bells tended to be EXTREMELY /circuit/ switched, which is
diametrically opposed to /packet/ switched.
- Bet on the wrong horse.
- Had to double down on any of the above.

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? Did Mother Bell see /any/
data transmission method as a threat? Why?

I think it would be rather naive to think that /nobody/ saw the
possibility of the Internet making things over a disparate distance
equal cost to access vs the distance based billing of local vs long
distance.

I wonder why? What was so different between the business models of
the 1990's and those of the 2020's that Centrex would no longer
be a cost-saver for firms which chose to use it?

I don't know of /any/ /single/ ILEC employee ever talking about
Centrex. I think they had decided that Centrex was an unwanted step
child by the 2000s when I was working on phone systems (PBXs / KSUs /
""Smart (read: dumb) phones / multi-line POTS). If I had known about
Centrex and the pricing would have been acceptable, I probably would
have done more with it.

Granted, the Coronavirus has caused a reexamination of work-at-home as
a viable real-estate strategy, but I think the /time/ spent on dialing, connecting, and suffering with the shortcomings of cellular calls,
like picket-fencing, fading, disconnecting, and - last but far from
least - being easily tapped by anyone with an antenna ana a few items
of listening equipment.

I don't do enough on cell to be able to comment. But I can say that
my recent messing with ISDN vs POTS in my house, the call connection
speed of ISDN is -- in a word -- /amazing/ to me compared to POTS.

I'm afraid comparing IP-based telephony to ISDN PRI links is the
ultimate race-to-the-bottom in voice communicaiton. As far as I can
tell, the only thing that makes SIP or VoIP or /any/ Internet-based
real-time service - don't forget streaming video - viable is a surplus
of bandwidth which will, inevitably, decline as paid-prioritization
methods and equpment take hold.

I think that VoIP /across/ /the/ /Internet/ is a questionable idea at
best. I also think that VoIP technology across the LAN is a very good technology. Especially if you have the LAN switches that can isolate
& prioritize VoIP.

With this in mind, both ISDN PRI and VoIP are communications protocols
which imply an underlying network. The former seems to be a vertical
market while the latter seems to be used ~> abused for anything and
everything.

I'm aware of some larger SIP trunks, which have supplanted ISDN PRI
trunks, that are using dedicated access circuits. As such the
dedication means that there will always be sufficient bandwidth.

--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to Bill Horne <malassQRMimilation@gmail.com>:

On 22 May 2022 12:11:50 -0400, Fred Goldstein wrote:

IT was better than a modem for Internet access, and that's what killed it as it
was coming out in the early 1990s -- the Bells hated the Internet, which
broke their locality-based business model, and while they couldn't attack
modem users per se, they could at least attack the most obvious Internet
user group, non-Centrex ISDN BRI users.

Why would the bells hate the Internet?

No per minute charges (other than what they could try to get for ISDN calls), no separations, no "value" pricing. It totally broke their business model. This was way before VoIP, they wanted data to pay by the minute too.

I wonder why? What was so different between the business models of the
1990's and those of the 2020's that Centrex would no longer be a
cost-saver for firms which chose to use it?

Phone switches have gotten a lot cheaper, wires haven't. Putting a PBX
in the customer's office is a lot cheaper than running every extension
back to the CO. I realize there were versions of Centrex that put the
switch on the client's premises but now it's just an expensive telco
managed PBX.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <20220529192147.GA29678@telecom.csail.mit.edu>,
Bill Horne <malQRMassimilation@gmail.com> wrote:

I'm going to have to descend from whatever foothold I used to have on
Mount Olympus, and admit that I don't understand how you could "nail
up" two bearer channels without disabling the ISDN line's capability
to carry phone calls.

We did not provide staff members' voice service, only the data
connection to our lab.

When the ISDN service ended, it was convenient for those of us who
switched to CLEC ADSL to have that extra known-clean pair to our
homes; folks who were trying to run ADSL on top of an existing
unbundled ILEC voice circuit had a much harder time with installation
and a great deal of finger-pointing between the two carriers.

(Of course now we all have our Internet connectivity via DOCSIS, and
much of this region -- although not Cambridge -- has three competing facilities-based carriers, Comcast, RCN, and Verizon FiOS.)

-GAWollman

--
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: fsxNet Usenet Gateway (21:1/5)

In article <O8SdnfjNCtEMEhP_nZ2dnUU7-LHNnZ2d@giganews.com>,
Doug McIntyre <merlyn@dork.geeks.org> wrote:

We always did 128k bonded connections with no issues. No mystery here.
The biggest problem was the customer equipment. Most of it sucked
hard.

In the early part of my career, I supported ISDN connections for staff
and faculty in my lab. This was before widespread cable ISP access
and overbuilding, but Bell Atlantic (as then was) had a special tariff
that allowed universities to get unmetered ISDN BRI lines installed at employees' homes. We used Ascend equipment to terminate a PRI in our
building, which also supported model dial-up. Normally we'd use a
smaller Ascend box (smaller than my current cable modem!) on the
residential end, and we'd configure it to nail up both B channels 24x7
and give each user a subnet.

We were still doing this in 2001 when I bought my condo, so I was
probably one of the only residential ISDN customers in my town. The
special rate was detariffed around 2003 so I had the former ISDN pair
ported to Speakeasy for ADSL service. Shortly thereafter, we made the
decision to stop supporting our own dial-in and retired the PRI and
modems. (It took only a few years after that to get to the point
where employees were simply expected to pay for their own Internet connectivity, rather than getting reimbursed for it -- likewise cell
phones.)

-GAWollman

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

***** Moderator's Note *****

My apologies to Garrett: this was supposed to have been published last
week, but it got stuck in a holding file for some reason.

Bill Horne
Moderator

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 | "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: fsxNet Usenet Gateway (21:1/5)