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:	Thu, 4 Dec 2008 23:05:29 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Saverio Mascolo <saverio.mascolo@...il.com>
cc:	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, 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.

2) The main benefit of maintaining VJ's one packet increment is the better 
interflow fairness on short time scale which again is a tradeoff.

>   window dynamics of  newreno cwnd behave  better, they are smoother.
> others cwnd seem chaotic.

"seem chaotic" (to humans) != chaotic btw. E.g., any rapid change may 
seem chaotic. Also utms buffers might "seem chaotic" btw :-) which 
makes your equation even more complex one (this is not a joke, I've 
actually probed its behavior a bit).


-- 
 i.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ