netdev - Re: TCP delayed ACK heuristic

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, 19 Dec 2012 12:59:39 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	rick.jones2@...com
Cc:	amwang@...hat.com, David.Laight@...LAB.COM, netdev@...r.kernel.org,
	greearb@...delatech.com, eric.dumazet@...il.com,
	shemminger@...tta.com, tgraf@...hat.com
Subject: Re: TCP delayed ACK heuristic

From: Rick Jones <rick.jones2@...com>
Date: Wed, 19 Dec 2012 10:39:37 -0800

> On 12/18/2012 11:00 PM, Cong Wang wrote:
>> On Tue, 2012-12-18 at 16:39 +0000, David Laight wrote:
>>> There are problems with only implementing the acks
>>> specified by RFC1122.
>>
>> Yeah, the problem is if we can violate this RFC for getting better
>> performance. Or it is just a no-no?
>>
>> Although RFC 2525 mentions this as "Stretch ACK Violation", I am still
>> not sure if that means we can violate RFC1122 legally.
> 
> The term used in RFC1122 is "SHOULD" not "MUST."  Same for RFC2525
> when it talks about "Stretch ACK Violation."  A TCP stack may have
> behaviour which differs from a SHOULD so long as there is a reasonable
> reason for it.

Yes, but RFC2525 makes it very clear why we should not even
consider doing crap like this.

ACKs are the only information we have to detect loss.

And, for the same reasons that TCP VEGAS is fundamentally broken, we
cannot measure the pipe or some other receiver-side-visible piece of
information to determine when it's "safe" to stretch ACK.

And even if it's "safe", we should not do it so that losses are
accurately detected and we don't spuriously retransmit.

The only way to know when the bandwidth increases is to "test" it, by
sending more and more packets until drops happen.  That's why all
successful congestion control algorithms must operate on explicited
tested pieces of information.

Similarly, it's not really possible to universally know if it's safe
to stretch ACK or not.

Can we please drop this idea?  It has zero value and all downside as
far as I'm concerned.

Thanks.

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