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]
Message-ID: <001d01c93a2a$023f2560$6c01a8c0@RHEELAPTOP>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ