netdev - Re: [PATCH] CUBIC v2.3 with new improved slow start

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:	Wed, 29 Oct 2008 20:54:04 -0400
From:	"Injong Rhee" <rhee@...u.edu>
To:	"Rick Jones" <rick.jones2@...com>,
	"Stephen Hemminger" <shemminger@...tta.com>
Cc:	"Injong Rhee" <rhee@....ncsu.edu>, <netdev@...r.kernel.org>
Subject: Re: [PATCH] CUBIC v2.3 with new improved slow start

In any situation where delayed acks screw things up, HyStart would work 
exactly like the old slow start. No harm is done. Since those long delayed 
acks are simply filtered out, HyStart would not detect the exit points 
correctly -- in this particular case, it would delay the exit point until 
packet losses occur. Then this is the behavior of the old slow start.

If some bad implementation causes HyStart to exit from slow start too early 
(before the full utilization of the network), then it can be a problem. But 
we have not found that case. Even over asymmetric paths, premature exits do 
not occur (well based on our own def of premature exits, of course).


----- Original Message ----- 
From: "Rick Jones" <rick.jones2@...com>
To: "Stephen Hemminger" <shemminger@...tta.com>
Cc: "Injong Rhee" <rhee@...u.edu>; "Injong Rhee" <rhee@....ncsu.edu>; 
<netdev@...r.kernel.org>
Sent: Wednesday, October 29, 2008 7:53 PM
Subject: Re: [PATCH] CUBIC v2.3 with new improved slow start


> Stephen Hemminger wrote:
>> On Wed, 29 Oct 2008 19:14:03 -0400
>> "Injong Rhee" <rhee@...u.edu> wrote:
>>
>>
>>>>This looks like a good optimization, it obviously needs more testing
>>>>because Linux always seems to find new broken hardware.  The areas
>>>>that need to be tested should include:
>>>> * MacOs has a broken version of delayed ack that might cause
>>>>   HyStart to radically underestimate.
>>>
>>>We tested with FreeBSD. I presume that it covers MacOS. We will look into 
>>>that.
>>
>>
>> No Darwin added some stupid code that holds off acks for up to 2 seconds.
>
> Is this Apple's reimplementation of the ACK avoidance heuristics in OSX 
> they used to have in previous versions of MacOS with the Mentat TCP/IP 
> stack?
>
> FWIW, HP-UX and Solaris also have ACK avoidance heursistics - they have a 
> Mentat history - although both should be pretty good and neither should 
> hold-off ACKs for two seconds...
>
> rick jones
> 

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