netdev - Re: [PATCH] tcp: fixes for DSACK-based undo of cwnd reduction during fast recovery

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: <CADVnQyn7czRocYV3-goTtwqCDg9MBv+bTHeZ-A8R4n45LH8L=g@mail.gmail.com>
Date:	Mon, 14 Nov 2011 18:03:37 -0500
From:	Neal Cardwell <ncardwell@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, ilpo.jarvinen@...sinki.fi,
	nanditad@...gle.com, ycheng@...gle.com, therbert@...gle.com
Subject: Re: [PATCH] tcp: fixes for DSACK-based undo of cwnd reduction during
 fast recovery

On Mon, Nov 14, 2011 at 3:23 PM, David Miller <davem@...emloft.net> wrote:
> From: Neal Cardwell <ncardwell@...gle.com>
> Date: Tue,  8 Nov 2011 13:07:11 -0500
>
>> (2) When the ACK field is below snd_una (the "old_ack" goto label),
>> process any DSACKs and try to send out more packets based on
>> newly-SACKed packets.
>
> This seems dubious.
>
> An older ACK should not have more uptodate SACK information than a newer
> ACK.
>

I grant that it is a rare corner case, but it is possible if there is
reordering and packet loss in both directions.

In fact, AFAICT the code path to handle this corner case is already
there: AFAICT we call tcp_sacktag_write_queue() in the old_ack code
path exactly because it is possible for old ACKs to carry SACK ranges
that we haven't seen yet. If this is not possible then it seems we
should remove the old_ack code path.

Let me try to lay out a specific example:

Suppose a sender sends packets 1-12, and there is lots of loss and
reordering in both directions.

Suppose the receiver sends the following ACKs with SACK blocks, in the
following order (using packet numbers rather than sequence numbers):

(1) ack 1, sack <3-4>
(2) ack 1, sack <3-4 6>
(3) ack 1, sack <3-4 6 8>
(4) ack 1, sack <3-4 6 8 10>
(5) ack 1, sack <6 8 10 12>
(6) ack 2, sack <6 8 10 12>

Note that starting at ACK (5) the receiver is limited by the fact that
TCP options can only hold 4 SACK ranges, so the SACK for 3-4 "falls
off" the SACK block set.

Now suppose the ACKs are reordered, and some are dropped, so that the
sender receives the ACKs in this order:

(6) ack 2, sack <6 8 10 12>
(1) ack 1, sack <3-4>

The arrival of (6) advances snd_una to 2. Now the question is what to
do when (1), with an ACK field below snd_una, arrives at the
sender. The existing code tags packets 3-4 as SACKed, but does not use
this newly SACK-tagged data to send out new data. This commit proposes
to use the newly SACK-tagged 3-4 to send out new data.

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