netdev - Re: Strange TCP behavior over HSDPA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B3A1284.2030101@gmail.com>
Date:	Tue, 29 Dec 2009 15:30:28 +0100
From:	Kristian Evensen <kristian.evensen@...il.com>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	netdev@...r.kernel.org
Subject: Re: Strange TCP behavior over HSDPA

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html