[Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N
Andrei Gurtov <gurtov@cs.helsinki.fi> Mon, 28 July 2003 23:41 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24831 for <tsvwg-archive@odin.ietf.org>; Mon, 28 Jul 2003 19:41:59 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hHcS-0001V7-1j for tsvwg-archive@odin.ietf.org; Mon, 28 Jul 2003 19:41:32 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SNfWo7005731 for tsvwg-archive@odin.ietf.org; Mon, 28 Jul 2003 19:41:32 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hHbx-0001Te-MK; Mon, 28 Jul 2003 19:41:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hHbB-0001Sj-1d for tsvwg@optimus.ietf.org; Mon, 28 Jul 2003 19:40:13 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24657 for <tsvwg@ietf.org>; Mon, 28 Jul 2003 19:40:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hHb9-0000zq-00 for tsvwg@ietf.org; Mon, 28 Jul 2003 19:40:11 -0400
Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19hHb8-0000zk-00 for tsvwg@ietf.org; Mon, 28 Jul 2003 19:40:10 -0400
Received: from cs.helsinki.fi (dhcp95.icir.org [::ffff:192.150.187.95]) (AUTH: PLAIN gurtov, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by mail.cs.helsinki.fi with esmtp; Tue, 29 Jul 2003 02:40:05 +0300
Message-ID: <3F25B467.9020609@cs.helsinki.fi>
Date: Mon, 28 Jul 2003 16:40:23 -0700
From: Andrei Gurtov <gurtov@cs.helsinki.fi>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tsvwg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
In go-back-N recovery TCP DUPACKs can result either from unnecessarily retransmitted packets or from a loss of a retransmitted packet. [Flo94] from RFC2892 shows that this ambiguity can cause unnecessary fast retransmits. A solution called "bugfix" in [F98] disables fast retransmits until go-back-N recovery is completed. However, because the ambiguity is not resolved, "bugfix" causes timeouts and very long recovery if packets get lost during go-back-N. The long-term solution to this problem is SACK (to prevent unnecessary retransmissions) and DSACK (to resolve the DUPACK ambiguity if unnecessary retransmissions do happen). However, most TCP connections today still do not use SACK. http://www.icir.org/floyd/sack-questions.html Until SACK is universally deployed two methods to resolve the DUPACK ambiguity might be useful. ACK-heuristic: if seq(ack_new)-seq(ack_prev)<=2 MSS then trigger fast retransmit on 3rd DUPACK This method is based on observation that to trigger a false fast retransmit, a TCP sender has to retransmit unnecessarily at least 3 adjucent packets. In this case there will be a jump in a cumulative ACK at the sender of at least three segments. Using the timestamp option: if ts_echo(ack_new) == ts (seg_una) then trigger fast retransmit on 3rd DUPACK In case of a missing segment both RFC1323 or RFC1323bis (expired update draft) require that DUPACKs echo a timestamp from the segment below the missing one. Some algorithm to detect spurious timeouts should be used before applying these tests. I'm currently running experiments in ns2 to identify any possible corner cases. For example, if ACKs get lost, a lost data segment would not be detected by the ACK-heuristic. However, if proposals work at least in common cases, using them is an improvement upon the "bugfix". Later I'll send a pointer to simulation results. Andrei _______________________________________________ tsvwg mailing list tsvwg@ietf.org https://www1.ietf.org/mailman/listinfo/tsvwg
- [Tsvwg] resolving the problem of unnecessary fast… Andrei Gurtov
- Re: [Tsvwg] resolving the problem of unnecessary … Mark Allman
- Re: [Tsvwg] resolving the problem of unnecessary … Andrei Gurtov