Re: A telephony carrier industry perspective
- To: "Khaled Amer" <khaledamer@xxxxxxx>
- Subject: Re: A telephony carrier industry perspective
- From: Fred Baker <fred@xxxxxxxxx>
- Date: Sun, 23 May 1999 17:54:22 -0700
- Cc: stds-802-3-hssg@xxxxxxxx, stds-802-qos-fc@xxxxxxxx
- In-Reply-To: <03f101bea4ce$ee7adc40$43c0fea9@sonyvaio>
- References: <99052003132472/0004245935DP1EM@xxxxxxxxxxx>
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
At 10:33 PM 5/22/99 -0500, Khaled Amer wrote:
>>From my point of view, and based on the analysis that I've been doing, as
>well as research I've been reading, it seems to me that flow control at L2
>is needed in general, and becomes more and more important as we scale up LAN
>speeds. I also believe that it should be done in a fashion that
>differentiates between different types of traffic.
As one who has done both, I have to point out that you need session
recovery at the transport layer (TP-0 equivalent) even if you have reliable
link layers - X.25 found that out in a big way, with flow control at link,
network, and transport layers. If we were using flow control as envisaged
in LLC or HDLC, a go-back-n protocol with a frame counter of up to 127
frames, the current Internet would be in deep trouble with all of its long
fiber. Running in the JANET ATM research network, individual TCP sessions
running on ATM OC-3 require 128K windows to fill the link, and longer fiber
or higher speed increases that requirement. If you are going to do that,
you'd best make for much larger windows than are normally allowed in
HDLC-style protocols.
I also have to point out that today's Internet started with reliable link
layers (BBN 1822, X.25/LAPB, and LAPB between routers) and found that it
operated far more efficiently without them. In today's backbone, ATM is in
use because it permits traffic engineering and gives service providers
fiber rate. ATM Forum likes to say it is because of the intelligent network
model, and because of ATM' QoS features. But as they go to higher speed,
the service providers (here I am quoting the CTOs of MCI Worldcom, Cable
and Wireless, Sprint, Optus, Qwest, Level 3, Verio, British Telecom, and
others) are finding that ATM SARs don't exist at OC-48 and OC-192, but MPLS
(which offers traffic engineering features) and Packet on SONET do. They
are discarding ATM as quickly as they can get away from it, observing that
they never used ATM's QoS features and that whatever gives them the
bandwidth is what they want to use.
That line of reasoning doesn't bode well for your argument.