Re: Strange TCP behavior over HSDPA

[Kristian Evensen <kristian.evensen@gmail.com>]

Den 29.12.2009 14:36, skrev Jarek Poplawski:
> On Tue, Dec 29, 2009 at 12:16:24PM +0000, Jarek Poplawski wrote:
>    
>> On Tue, Dec 29, 2009 at 10:57:48AM +0000, Jarek Poplawski wrote:
>>      
>>> Did you try to turn off TCP window scaling btw? Anyway, under the
>>> tunnel ([2]), when SACK worked, it saved you a lot of retransmits.
>>>        
>> Hmm... Actually, after re-checking, there weren't much more of those
>> retransmits at all. In [1] there was one more packet lost, so it took
>> a bit longer. In [2] (with SACK) the retransmit started earlier and
>> the rcv window was unchanged. So, it rather looks like differences
>> in timing of TCP recovery techniques.
>>      
> Hmm#2... On the other hand, I can imagine cases with a larger data
> loss, where working SACK should really save on retransmits.
>
> Jarek P.
>    
Thanks for all your comments. I have not tried to disable window 
scaling, but will try that as soon as possible. I also noticed the 
second packet loss in [1], but I don't think it affected the situation 
to much. In similar packet captures, the transfer without the tunnel has 
only lost one packet and the throughput drop has been just as 
significant as in [1]. It rather seems to be, as you point out, 
differences in timing of the recovery techniques, probably between this 
accelerator and the server.

However, I find it a bit strange the dupAcks are sent back to the 
server. Based on my, I must admit limited, knowledge of accelerators, 
they will buffer and ACK packets if they for example are responsible for 
retransmissions. But again, maybe it uses the dupAcks to tell the server 
to slow down and then simply discards the retransmitted packet.

-Kristian