The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Sep> msg00017



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Alternate Encapsulations/Signals for IP on AAL5

  • From: Curtis Villamizar <curtis@ans.net>
  • Date: Fri, 08 Sep 1995 13:06:27 -0400
  • CC: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, ip-atm@matmos.hpl.hp.com


In message <199509080956.KAA22486@cleo.madge.co.uk>, Mike Moreton writes:
> > 2/ TCP on IP on AAL5 on an ABR service
> > 
> > we'd like an explicit congestion bit (even if ATT don';t let us get
> > the explicit rate,they'll still pass the congestion signal back sooner
> > than packet loss in traditional TCP congestion detection) signal from
> > AAL up thu IP....
> 
> I'm interested why you 'd want this.  Without it, down at the SAR level
> transmission of your traffic will get slowed down because of the congestion
> indication coming back, and may get queued for a while.  TCP will run
> out of window, and hence stop.

In a lot of real world applications, TCP doesn't "run out of window"
until huge delays are incurred.  In order to acheive high performance,
the window limit must be set quite large (you need a 380KB window if
you are trying to go cross country (US) and expect that under good
conditions you'd get something on the order of DS3 performance.  Gets
worse if you cross oceans.  This is a universal constant, not unique
to TCP.  The traditional means to tell TCP to slow down a bit is an
isolated packet drop.  Floyd in tcp_ecn*.ps proposed to use a
"congestion bit" and "congestion bit aware bit" in TCP rather than an
isolated packet drop as the method of indication.

> If you let TCP handle the congestion indication rather the hardware, wouldn't
> you just be moving the queue of slowed down data somewhere else?
> 
> Mike.

You'd move it all the way back to the end system.  If the end
application is elastic and capable of producing a sustained rate of
traffic exceeds the network's capacity, that is where you would want
to move the bottleneck.  Some applications which send time varying
information are actually smart enough to react to a block on a TCP
write (BGP speakers for example) rather than keep stuffing the queue
with information that might change.  For bulk transfer applications,
you would just not read it off the disk drive until the network write
became unblocked (given finite TCP queueing on the sending host for
packets in flight).

Curtis