crk@research.att.com Mon, 12 July 1993 22:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28252; 12 Jul 93 18:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28248; 12 Jul 93 18:29 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa11995; 12 Jul 93 18:29 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29937; Mon, 12 Jul 93 15:21:46 PDT
Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA17728; Mon, 12 Jul 93 15:21:47 PDT
Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20479; Mon, 12 Jul 93 15:20:17 PDT
Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA20473; Mon, 12 Jul 93 15:20:16 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA24159; Mon, 12 Jul 93 15:20:21 PDT
Received: from research.att.com by Sun.COM (4.1/SMI-4.1) id AA29648; Mon, 12 Jul 93 15:20:02 PDT
Message-Id: <9307122220.AA29648@Sun.COM>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: crk@research.att.com
Date: Mon, 12 Jul 1993 18:18:00 -0400
To: atm@sun.com
Re: TCP loss rate over ATM
X-Orig-Sender: atm-request@atm.eng.sun.com

Given Allyn's assumptions of small buffers, large packets and 
the existing TCP mechanism for window size increases, it is 
not surprising that the packet loss rate of TCP over ATM is 
higher than that of packet-TCP.  There are a number of ways
that this could be addressed.

We could use peak rate allocation for each connection.  This
is the only approach that is currently part of the ATM standards.
While this works well for some types of traffic, it leads to
extremely inefficient use of network bandwidth for data traffic, 
which has a high peak-to-average ratio.  This approach is not a 
real contender for data.

Another option is to do some form of burst-level reservation.  
We have investigated burst-level buffer reservation and show
that it is possible to run TCP over ATM _with no congestion
induced packet losses_ while operating the network at 85%
efficiency.  (This work soon to appear in the Journal of 
ISDN and Computer Systems).  The drawback of this approach
is the additional complexity of the burst-level signaling.

Keshav describes a third approach to the problem, which suggests a
evolution path for ATM switches and for end-systems.  

    1) In order to handle data traffic effectively, ATM switches 
       should be designed with large buffers, buffer reservation
       for each VC, and round-robin scheduling.  We have demonstrated 
       the feasibility of running a round-robin scheduler for a 1 Gb/s 
       port on an ATM switch in XUNET.  The amount of buffer that is 
       needed depends on a number of things, but it is likely that some 
       small number of round trip windows will be more than adequate.

    2) End-systems can use a much more intelligent congestion
       avoidance mechanism by using the packet-pair scheme to
       adapt their sending rate.  

Even if some end-systems fail to play by the rules, the round-robin 
scheduler insures that other users are not adversely affected (the
``firewall'') and bandwidth is allocated fairly among the users who 
wish to share the network.  

ATM is an emerging technology and so is still a tabula rasa.  The
benefits of round-robin scheduling and packet-pair have been 
demonstrated and in the same way that router vendors have 
begun to recognize the importance of fair-queueing, it would
seem likely that ATM switch vendors would want to incorporate
round-robin scheduling and so sell a superior product.

chuck kalmanek
  •   crk