netdev - Re: TCP default congestion control in linux should be newreno

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:	Thu, 4 Dec 2008 15:56:13 -0800
From:	"John Heffner" <johnwheffner@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	"Saverio Mascolo" <saverio.mascolo@...il.com>,
	"David Miller" <davem@...emloft.net>, ldecicco@...il.com,
	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP default congestion control in linux should be newreno

On Thu, Dec 4, 2008 at 1:05 PM, Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> wrote:
> On Thu, 4 Dec 2008, Saverio Mascolo wrote:
>
>> we have done many experiments, along with many other "researcher" as u
>> say. as a consequence, i have maturated the belief that changing the
>> probing phase of the van jacobson TCP, which is linear, could not be
>> not a wise thing .
>>  the rationale of  VJ choice seems simple to me: if  the window is
>> increased of one packet in one rtt, i can drop at most one packet in
>> one rtt and so i have to recover only one packet in one rtt (note that
>> rtt is the feedback reaction  time). If cwnd is increased of N packets
>> i could drop N packets and i could need to recover N pkts. this is the
>> problem here.
>
> 1) N drops is not as bad as you seem to imply, sadly this is a very common
> misconcept among much tcp related research that fast retransmits and the
> following recovery are a bad things in itself. SACK handles it very
> efficiently as long as N is considerably less than cwnd and the buffer
> before the bottleneck was adequate to keep the link fully utilized over
> that recovery rtt. Thus the first claim (vj one) does not follow from the
> latter on (n pkts is bad), it is bogus reasoning.

One thing to note, you only get N drops upon cwnd increase of N when
you have simple drop-tail queues.  AQM significantly changes the
behavior here, but drop-tail is still nearly ubiquidous.

A notable effect of multiple loss associated with increasing cwnd by
multiple segments, aside from outright SACK bugs, is that it tends to
synchronize losses across flows, since all N drops are not usually
from the same flow.  (Again, talking only about drop-tail here.)
Synchronized losses lead to lower link utilization with many flows.

  -John
--
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