Cell Relay Archive

Cell Relay Retreat>List Archive>month:1995-Apr> msg00340



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

Re: TCP window size? Cell-level pacing?

  • From: Bill Halverson <wjhalv1@pacbell.com>
  • Date: Fri, 21 Apr 1995 20:12:51 -0500, 22 Apr 1995 00:43:04 GMT

"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? 
 
> 
>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... 
> 
>And finally, I was able to get a little more throughput by setting 
>the NODELAY flag with setsockopt().  But this was on our LAN.   
>What effect will the NODELAY flag have when pushing info over an 
>ATM WAN?  Will it potentially cause problems? 
 
Hmmmm ... probably no effect whatsoever. 
 
Turns out at gigabit speeds the TCP buffer/window closes before the 
ACK comes back from the far end.   
 
> 
>Thanks for any and all help, suggestions, and pointers to info! 
> 
>Scott D. Weberg 
>Computer Scientist 
>U.S. Army Corps of Engineers 
 
 
---------------------------------------------------------------- 
Bill Halverson    Pacific  Bell    Sent 17:45:00 PDT on 04/21/95  
PH 415 542 6564  wjhalv1@pacbell.com            FAX 415 542 6424  
"The views of the author are not those of his employer ... yet."