[Tsvwg] new revision of early retransmit available

Mark Allman <mallman@grc.nasa.gov> Fri, 22 August 2003 16:28 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 MAA05693 for <tsvwg-archive@odin.ietf.org>; Fri, 22 Aug 2003 12:28:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qElg-00031N-5D for tsvwg-archive@odin.ietf.org; Fri, 22 Aug 2003 12:28:04 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MGS46T011607 for tsvwg-archive@odin.ietf.org; Fri, 22 Aug 2003 12:28:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qEld-00030R-5L; Fri, 22 Aug 2003 12:28:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qElU-000306-Rg for tsvwg@optimus.ietf.org; Fri, 22 Aug 2003 12:27:52 -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 MAA05681 for <tsvwg@ietf.org>; Fri, 22 Aug 2003 12:27:47 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qElT-0006fa-00 for tsvwg@ietf.org; Fri, 22 Aug 2003 12:27:51 -0400
Received: from seraph2.grc.nasa.gov ([128.156.10.11]) by ietf-mx with esmtp (Exim 4.12) id 19qElS-0006fS-00 for tsvwg@ietf.org; Fri, 22 Aug 2003 12:27:50 -0400
Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7BD6B68A13 for <tsvwg@ietf.org>; Fri, 22 Aug 2003 12:27:20 -0400 (EDT)
Received: from guns.grc.nasa.gov (guns.grc.nasa.gov [139.88.122.88]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h7MGRKld016289 for <tsvwg@ietf.org>; Fri, 22 Aug 2003 12:27:20 -0400 (EDT)
Received: from guns.lerc.nasa.gov (localhost.lerc.nasa.gov [127.0.0.1]) by guns.grc.nasa.gov (Postfix) with ESMTP id E2F0B3BB3F8 for <tsvwg@ietf.org>; Fri, 22 Aug 2003 12:27:19 -0400 (EDT)
To: tsvwg@ietf.org
From: Mark Allman <mallman@grc.nasa.gov>
Reply-To: mallman@grc.nasa.gov
Organization: BBN Technologies/NASA GRC
Song-of-the-Day: Ticket to Ride
Date: Fri, 22 Aug 2003 12:27:19 -0400
Message-Id: <20030822162719.E2F0B3BB3F8@guns.grc.nasa.gov>
Subject: [Tsvwg] new revision of early retransmit available
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>

 
Folks-

We have just sent a new version of the Early Retransmit internet
draft to the secratariet.  It should appear in the archives in a
couple of days.  It is available from:

 http://roland.grc.nasa.gov/~mallman/papers/draft-allman-tcp-early-rexmt-02.txt

now.

The largest change in the document is that it now includes a variant
that uses SACK information to make ER more robust.  The problem that
we have found is that the instances where ER will help are windowed
quite a bit when it just counts duplicate ACKs.

First consider two states the reciever could be in....

  * S1: the receiver has ACKed all data received
  * S2: the receiver has received a packet but is delaying its ACK
    for another arrival (or the timer)

When the receiver is in S1 and an out-of-order segment arrives a dup
ACK will be triggered and ER will work nicely (or, as nicely as
possible).

When the receiver is in S2 and an out-of-order segment arrives the
receiver will send an immediate ACK, but it will not be a duplicate
-- but, rather it will cover previously unACKed data.  In this case,
ER is not in a happy place because it expects a duplicate ACK from
all but one of the segments outstanding.

So, we (meaning Josh, really) figured out that if we leveraged SACK
information we could just tell when all but one packet has arrived
at the receiver and key on that for ER, rather than try to count
duplicate ACKs.  (Because even if the ACK for out-of-order data is
cumulatively ACKs previously unACKed data (i.e., is not a dup ACK)
it will still have SACK information indicating what packet triggered
the ACK.)  This scheme seems more robust.

At the moment both schemes are in the draft.  But, we are seriously
considering ripping out the version that does not use SACK on the
grounds that if you're not using SACK and you are interested in good
loss recovery in 2003 then you really can't be all that interested.
(Recent measurements: I am seeing > 90% of web clients support SACK
at a web server I am watching.  I ran tbit against 61,000+ web
servers and 65% support SACK.)

We'd be interested in getting feedback on any of the above issues
(and the text of the draft itself, of course).

Thanks!

allman

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg