LARTC - Jul 2007 - Fwd: PFIFO to contain more pkts than allowed by TCP peer?

Maybe this is the right place to ask?

Thanks again,
Daniel


Begin forwarded message:
> From: Daniel Schaffrath <daniel.schaffrath@mac.com>
> Date: 21 July 2007 11:01:01 GMT+02:00
> To: linux-net@vger.kernel.org
> Subject: PFIFO to contain more pkts than allowed by TCP peer?
>
> Hello everybody,
>
> when the one and only connection originating my box is a TCP stream  
> which is limited by the advertised window of my peer at - lets say  
> - 47 pkts, I would expect ''tc -s qdisc show'' to show at
most 47
> pkts in the pfifo of the appropriate device. Unfortunately, this is  
> not the case. It''s around 83 (twice as much??). Anyone any hints  
> how come?
>
> Thank you,
> Daniel
> -
> To unsubscribe from this list: send the line "unsubscribe linux- 
> net" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Daniel Schaffrath wrote:
> Maybe this is the right place to ask?
> 
> Thanks again,
> Daniel
> 
> 
> Begin forwarded message:
> 
>> From: Daniel Schaffrath <daniel.schaffrath@mac.com>
>> Date: 21 July 2007 11:01:01 GMT+02:00
>> To: linux-net@vger.kernel.org
>> Subject: PFIFO to contain more pkts than allowed by TCP peer?
>>
>> Hello everybody,
>>
>> when the one and only connection originating my box is a TCP stream 
>> which is limited by the advertised window of my peer at - lets say - 
>> 47 pkts, I would expect ''tc -s qdisc show'' to show at
most 47 pkts in
>> the pfifo of the appropriate device. Unfortunately, this is not the 
>> case. It''s around 83 (twice as much??). Anyone any hints how
come?
Maybe tcp window scaling - you can tcpdump the syn/syn ack of the 
connection to see what if any scale factors are being used.

If pfifo is just on the root of a device rather than as a child of 
something that retelimits, then there could be 100s of packets in a 
further buffer before you even see a backlog.

Andy.