[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