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 16:26:30 +0100
From:	"Saverio Mascolo" <saverio.mascolo@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP default congestion control in linux should be newreno

On Thu, Dec 4, 2008 at 1:41 PM, Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> wrote:
> 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!

2.6

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

bic is default since a couple of years, at my by knoweledge. btw now it is.

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

what matters is goodput. if protocols A and B provide same goodput the
better is the one with lowest retransmissions because retrans. waste
bandwidth


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

using a more aggressive probing (more than linear) increases retransmissions.

sm
>
>
> --
>  i.
>



--
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:mascolo@...iba.it

http://www-dee.poliba.it/dee-web/Personale/mascolo.html


=================================
This message may contain confidential and/or legally privileged information.
 If you are not the intended recipient of the message, please destroy it.
Any unauthorized dissemination, distribution, or copying of the material in
this message, and any attachments to the message, is strictly forbidden.
--
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