Re: A telephony carrier industry perspective

[Roy Bynum <rabynum@xxxxxxxxxxx>]

Fred,

You might be surprised at how much TCP/IP is still being carried over
X.25 in third world countries.  The problem with X.25 is lack of
bandwidth.  While X.25 tends to prevent the loss of data, the bandwidth
restrictions cause applications to time out because of slow responce. 
This gets really bad when there is too much traffic.  I worked on a
project in Mexico that had this problem.  The ISP that was using X.25
was moved to Frame Relay (FR), then to ATM when FR got too congested.

ATM allows Internet transport to create logical full mesh systems using
PVCs over a partial mesh of SONET circuits.  The PVCs allow traffic to
transit a site without doing the switching at layer 3.  This reduces the
amount of routing processing and thus tends to reduce latency at the
router/gateway nodes.

The complexity of creating and maintaining the PVC architecture is
becoming unworkable.  The dynamics of restoration processes between the
ATM and IP are more and more complex.  The extreem level of complexity
is limiting the scalablity of ATM for the core of the Internet.  Combine
the operations and support costs with high equipment costs and you can
see why the Internet is moving away from ATM as the core transport.  The
Internet is gambling on MPLS as the replacement for ATM.  Some sources
say that MPLS will be out of scalability by 2002 or 2003.  

I am hoping that the dynamic MAC level leaning architecture of switched
802.3 will provide some relief for the complexity of the Internet core. 
The combination of flow control with priority queueing may provide the
needed to tools to acomplish that.  At present it is being looked at. 
The limitation is the number of vendors that support OSPF, BGP4, flow
control and priority queuing in the same L2/L3/L4 switch.  As more
vendor bring out systems that support these protocols, it will be easier
to do.

					Thank you,
					Roy Bynum 



Fred Baker wrote:
> 
> 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.