netdev - Re: [PATCH 3/5] tcp: use SACKs and DSACKs that arrive on ACKs below snd

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:	Sun, 27 Nov 2011 18:57:29 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	ncardwell@...gle.com, netdev@...r.kernel.org, nanditad@...gle.com,
	ycheng@...gle.com, therbert@...gle.com
Subject: Re: [PATCH 3/5] tcp: use SACKs and DSACKs that arrive on ACKs
 below snd_una

From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Thu, 17 Nov 2011 03:52:37 +0200 (EET)

> On Wed, 16 Nov 2011, Neal Cardwell wrote:
> 
>> The bug: When the ACK field is below snd_una (which can happen when
>> ACKs are reordered), senders ignored DSACKs (preventing undo) and did
>> not call tcp_fastretrans_alert, so they did not increment
>> prr_delivered to reflect newly-SACKed sequence ranges, and did not
>> call tcp_xmit_retransmit_queue, thus passing up chances to send out
>> more retransmitted and new packets based on any newly-SACKed packets.
>> 
>> The change: When the ACK field is below snd_una (the "old_ack" goto
>> label), call tcp_fastretrans_alert to allow undo based on any
>> newly-arrived DSACKs and try to send out more packets based on
>> newly-SACKed packets.
>> 
>> Other patches in this series will provide other changes that are
>> necessary to fully fix this problem.
>> 
>> Signed-off-by: Neal Cardwell <ncardwell@...gle.com>
 ...
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>

Applied to net-next.

> ...unrelated to the fix, I realized that FRTO is not fully thought through 
> in this old ACK case, also its RFC seems to lack considerations on what to 
> do in such case. ...I'll need to think the FRTO stuff a bit more.

Every feature added to TCP beginning with timestamps has not been well
thought out wrt. reordering. :-)
--
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