[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1376940568-16512-1-git-send-email-christoph.paasch@uclouvain.be>
Date: Mon, 19 Aug 2013 21:29:26 +0200
From: Christoph Paasch <christoph.paasch@...ouvain.be>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org, Phil Oester <kernel@...uxace.com>,
Corey Hickey <bugfood-ml@...ooh.org>,
Benjamin Hesmans <benjamin.hesmans@...ouvain.be>
Subject: [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks
There exist sequence-number rewriting middleboxes, who do not modify the
sequence-number in the SACK-blocks.
Duplicate acknowledgments with these (invalid) SACK-blocks will not be
accounted in sacked_out, and thus no fast-retransmit will trigger.
So, the only way to recover from a packet-loss is through an RTO,
effectively killing the performance of TCP in this case.
Performance-results can be seen here:
http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
Another solution might be to simply disable SACK, as soon as an invalid
SACK-block has been received (as suggested by Phil Oester). This however
might be too aggressive.
Christoph Paasch (2):
Use acked_out for reno-style ack acounting instead of sacked_out
Account acked_out in sack, if the sack is invalid
include/linux/tcp.h | 1 +
include/net/tcp.h | 17 +++++---
net/ipv4/tcp_input.c | 103 ++++++++++++++++++++++++++++++++---------------
net/ipv4/tcp_minisocks.c | 1 +
net/ipv4/tcp_output.c | 6 +--
net/ipv4/tcp_timer.c | 2 +-
6 files changed, 89 insertions(+), 41 deletions(-)
--
1.8.1.2
--
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