[c-nsp] TCP behavior under strict CAR rate-limiting

[Christopher Hunt]

Bill, Sake et al.,
    Thanks for taking the time to check into this.  I've posted a zip 
containing the orginal .pcap/.cap files from both ends of the test plus 
the .txt translations and also a MS Word document containing the router 
output, testing results etc.   The file is at 
http://users.reachone.com/drsmooth/SmallBurst.zip . 
    I am familiar with TCP's concept of Slow Start, but my understanding 
is that it is the RWIN that is slow to start.  The packet does show the 
first packet as 24 Byte payload, but even then the client RWIN is 5888 
(scaled x7) (CentOS running 2.6.18 kernel).   The "server" is XP Pro 
running an RWIN 65535 with scaling disabled.  As far as I can tell, TCP 
slow start is not happenning.  What other signs of Slow Start should i 
be looking for?

Christopher Hunt

bill fumerola wrote:
> [ i deleted some of this thread already & am too lazy to search archives
>   to see if you posted tcpdumps, i'll go off what's in my mailbox. ]
>
> On Thu, Jun 19, 2008 at 02:22:39PM -0700, Christopher Hunt wrote:
>   
>>  Thanks for the reply.  I understand that those values are not 
>> recommended and in fact i do not use them outside of the lab.  I am, 
>> however, struggling to understand how TCP reacts to very very low burst 
>> levels.  What mechanism is causing such low throughput as the 
>> tcp_receive_window values are not low?
>>     
>
> the window settings may not be low, but i'd imagine that if you sniffed
> the traffic the actual window size never really ramped up.
>
> assuming this covers the entirety of the transaction:
>       conformed 188 packets, 260984 bytes; action: transmit                           
>       exceeded 65 packets, 97206 bytes; action: drop   
>
> you dropped 25% of the packets sent. the window never would have scaled
> up and even if the window did scale up before this policy was applied
> it would drop to 0 and slow start would begin again.
>
> tcp doesn't send an orgy of packets (a 16k window of packets) and then
> figure out how many landed where they should, it ramps / scales UP TO
> the max window size.  it was never afforded the opportunity to do so due
> to your incredibly small burst size causing these drops.
>
>
> -- bill
>