netdev - Re: FYI - TCP/IP thin stream latency

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]

Date:	Sat, 08 Nov 2008 11:16:17 +0000
From:	Douglas Leith <Doug.Leith@...m.ie>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	David Malone <David.Malone@...m.ie>
Subject: Re: FYI - TCP/IP thin stream latency

I finally managed to make time to read the paper by Mondal and  
Kusmznovic properly.

The basic argument made is that using removing RTO backoff (i.e.  
disabling the doubling of RTO on each timeout) cannot degrade flow  
completion time vs when RTO backoffs are allowed.   Therefore, there  
is no benefit from doing backoffs.

Although they have a "theorem" on this, unfortunately it seems to be  
flawed - see note attached.  Basically, their argument relies on the  
assumption (amongst other things) that all flows sharing a link are  
in lock-step so that their backoff stage is always the same, which is  
clearly not realistic.   Without this assumption, it seems quite  
possible that the completion time is shorter when backoff is used  
over when the RTO is fixed.  In fact its also possible that the  
aggregate sum of the completion times of *all* flows is lower with  
backoff than without.  I've emailed the authors to confirm that they  
agree, but it seems pretty clear cut.     I should stress that this  
is not to say removing RTO backoff is not a reasonable idea, just  
that the argument put forward in the paper doesn't seem to work as  
stated.

The trade-off here is a complex one between the delay introduced by  
sending packets at a lower rate i.e. with wider spacing between  
packets vs the delay incurred by increased retransmissions when  
packets are sent at a higher rate due to the higher loss rate.   I  
reckon the paper doesn't really deal with common concerns regarding  
congestion collapse or with application-limited low-speed flows (e.g.  
games traffic).   For example, an RTO of 200ms still seems like a  
problem for the delay-sensitive games traffic.   We have a student  
starting soon, so my plan is to ask him to do some more RTO tests to  
see if some light can be cast on these.

Cheers,

Doug

Download attachment "ccr_note.pdf" of type "application/pdf" (27559 bytes)

On 24 Oct 2008, at 15:59, Stephen Hemminger wrote:

> I was  reading "Removing Exponential Backoff from TCP" by Mondal  
> and Kusmznovic at Northwesetern
> in ACM CCR. The paper tries to show that nothing breaks by getting  
> rid of backoff. Interestingly,
> FreeBSD already doesn't do backoff until after 5th retry.