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

Date:	Thu, 4 Dec 2008 14:41:05 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Saverio Mascolo <saverio.mascolo@...il.com>
cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP default congestion control in linux should be newreno

On Wed, 3 Dec 2008, Saverio Mascolo wrote:

> we have added plots of cwnd at
> 
> http://c3lab.poliba.it/index.php/TCP_over_Hsdpa
> 
> in the case of newreno, wetwood+, bic/cubic.

You lack the most important detail, ie., the used kernel versions! And 
also information if some sysctls were tuned or not. This is especially 
important since you seem to claim that bic is the default which it hasn't 
been for years?!

> basically the goodput is similar with all variants  but with
> significantly larger packet losses and timeouts with bic/cubic.

I've never understood what exactly is wrong with the larger amount of 
packet losses if they happen before (or at the bottleneck), here they're 
just a consequence of having the larger window.

> i am pretty sure that this would happen with any algos -including h-tcp-
> that makes the probing more aggressive leaving the van jacobson linear
> phase.

Probably, but you seem to completely lack the analysis to find out why the 
rtos did actually happen, whether it was due to most of the window lost or 
perhaps spurious rtos?

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