Cell Relay Archive

[c.oneill@trl.oz.au (Chris O'Neill)]

In article <3n9jeo$k3e@gw.PacBell.COM>, Bill Halverson
<wjhalv1@pacbell.com> wrote:

|"Scott D. Weberg" <sweberg@wes.army.mil> wrote: 
| 
|>I keep reading that the TCP window size has a lot to do with how 
|>fast you can push data thru a unix socket over ATM.  So I went 
|>snooping around, trying to figure out how to set the TCP window 
|>size.  Well, I am assuming that it is configured in the kernel, or 
|>something like that.  I found out how to set the send/receive 
|>buffer sizes, using setsockopt().  I also found out about the  
|>maximum TCP segment size, which cannot be set by the application, 
|>but is set by the hardware at the time a connection is made. 
|> 
|>But I still don't know what the "TCP window size" is - and how it is 
|>set.  There seems to be no socket routines that allow you to set 
|>the TCP window size.  Can someone tell me how you set it?  Is it 
|>something the sys admin has to do? 
| 
|I think the buffer size is equivalent to the TCP window size.  Can you   
|set a different value for each socket, if you chose to? 

As suggested in another post, please read Van Jacobson's paper in Sigcomm
88.  Anyone wondering about TCP windows is wasting their time thinking
about the subject until they read this paper.

|>My next question is about cell-level pacing.  I read a paper 
|>(TCP/ATM Experiences in the MAGIC Testbed) that suggested that cell- 
|>level pacing dramatically improves throughput over an ATM WAN. 
|>What is cell-level pacing?  How do you go about implementing it? 
|>Does it apply at the unix socket level, or at the ATM level? 
| 
|AH ... cell level pacing ... I bet this is another way of saying 
|"we must gate cells onto the network access link at a rate compatible   
|with the cell buffers associated with the incoming physical ports of our   
|ATM switch, otherwise we will run out of buffer space and drop cells". 
| 
|I saw this happen last year in a transcontinential ATM network I was 
|involved with.  Some really clever people came up with a tidy workaround 
|for it. 
| 
|My guess is you have to deal with it before it gets to the ATM layer, 
|because right now there are no accepted standards on "traffic shaping". 
| 
|Maybe the ATM crowd can help us out here... 

ATM traffic management to support applications now controlled with TCP is
in a developmental state.  The standard for this (available bit rate, ABR)
is due to be released this year.  Until then there is no standardised way
of efficiently supporting traffic that is now controlled with TCP (i.e.
data traffic).  There are some proprietary solutions and the problem can
be solved to some degree with large buffers.  However, there are many
switches which are poorly suited to carrying such traffic.

|Turns out at gigabit speeds the TCP buffer/window closes before the 
|ACK comes back from the far end.   

Please read RFC 1323, "TCP extensions for high performance".  This shows
how the maximum TCP window size can be extended to 4Gbytes, more than
enough for gigabit speeds.

Chris O'Neill
Telecom Australia Research Labs