netdev - Re: [RFC] tcp: make H-TCP the default congestion control

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:	Wed, 03 Dec 2008 11:04:54 +0000
From:	Douglas Leith <Doug.Leith@...m.ie>
To:	Sangtae Ha <sangtae.ha@...il.com>
Cc:	Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [RFC] tcp: make H-TCP the default congestion control

>
> The slow convergence of CUBIC had been addressed through CUBIC v2.1
> and CUBIC v2.2 by removing the clamping of CUBIC growth function and
> making CUBIC more aggressive for fast convergence.
> So, I expect you talk about the latest update (CUBICv2.3) which
> integrates a new slow start, called HyStart.
>
> The second parameter of HyStart, which is a delay parameter, is
> designed to respect the existing flows.
> Which means that the later joining flow starts from the congestion
> window where it is believed to be safe not incurring packet losses to
> the existing flows.
> After that, it tries to share the link progressively (not depriving
> all of others bandwidth at once during slow start).
>
My comments related to the current cubic implementation, not the  
proposed new version.   I (not anyone else I don't think) has carried  
out any tests on this new version yet.

That said, even under best case circumstances is not at all clear  
that *any* change in slow start can properly address the slow  
convergence issues in cubic (or other proposals for that matter).   
All it needs is for an early packet loss to lead to an exit from slow  
start and then convergence is back to being determined by congestion  
avoidance behaviour, which remains slow.    Similarly, recovery to  
fairness following a UDP disturbance (or anything else that does not  
cause slow start to kick in) will be determined by the congestion  
avoidance behaviour, and so remain slow.

That is under best case conditions.  If the modified slow start makes  
a mistake (which seems like a reasonable concern since its trying to  
so dome quite fancy stuff based on limited information about the  
network, often early in the flow lifetime) then its not clear what  
the impact on convergence might be even when everything is otherwise  
going our way.
>
--snip-
>
> Could you try your testings with the following changes? We definitely
> will have testings like you mentioned and post the results.
>
Will do.  Got a deadline this week but I'll try to make some time  
next week.

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