netdev - Re: TCP reordering and Multiple DL path

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] [day] [month] [year] [list]

Date:	Tue, 11 Mar 2014 14:40:00 +0000
From:	"Zimmermann, Alexander" <Alexander.Zimmermann@...app.com>
To:	"Soum, Redouane" <redouane.soum@...el.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: TCP reordering and Multiple DL path


Am 10.03.2014 um 17:15 schrieb Eric Dumazet <eric.dumazet@...il.com>:

> On Mon, 2014-03-10 at 15:44 +0000, Soum, Redouane wrote:
>> Hi,
>> 
>> I have several path in DL between an Application Processor and a Modem
>> using different network interfaces (USB CDC NCMs) with the same ip
>> address (connected to the same network)
>> 
>> Having several network interfaces used in DL implies to have out of
>> order packets, even if the ooo packets will most likely come close
>> together.
>> 
>> Here is my understanding on the impact on TCP throughput :
>> 
>> -        OOO packets will lead to Dup acks.
>> -        When sender receives 3 Dup acks it'll start fast recovery
>> which will reduce TCP congestion window.
>> 
>> First question is my understanding correct ?
>> 
>> Assuming it is : 
>> In order to solve that issue I am thinking to add a small delay before
>> sending dup acks for OoO packets.
>> The objective is to be sure that dup acks for OoO packets will only be
>> sent for OoO packet due to different path in the network, and not
>> because of the different network interfaces.
>> 
>> However I am not sure how complex it would be to implement and which
>> part of the TCP stack need to be modified.
>> Any advice to solve that issue ?
> 
> This is quite complex.

Indeed. They are currently some efforts in TCPM to specify a reordering
robust TCP. See

http://tools.ietf.org/id/draft-zimmermann-tcpm-reordering-detection-00.txt
http://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-reaction-00.txt

Alex

> 
> Note that we are working on a more generic solution, involving a high resolution timer,
> for not only this case, but more generally :
> 
> Delayed ACK (application could tell TCP stack its max latency for RPC)
> 
> TSO autodefer bugs (currently we rely on future ACKS, while we should
> not)
> 
> TCP_CORK_US (extend TCP auto cork with a usec timer)
> 
> Trick is to not add uncontrolled jitter on ACKs, otherwise we screw up
> delay based CC.
> 
> 
> 
> --
> 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


Download attachment "signature.asc" of type "application/pgp-signature" (204 bytes)