The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Alternate Encapsulations/Signals for IP on AAL5
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 |
|