Re: [Tsvwg] Issues with draft-blanton-dsack-use-02

Sourabh Ladha <ladha@mail.eecis.udel.edu> Fri, 15 August 2003 11:47 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 HAA24975 for <tsvwg-archive@odin.ietf.org>; Fri, 15 Aug 2003 07:47:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nd2Z-0007Cy-Nc for tsvwg-archive@odin.ietf.org; Fri, 15 Aug 2003 07:46:44 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FBkhEQ027702 for tsvwg-archive@odin.ietf.org; Fri, 15 Aug 2003 07:46:43 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nd1s-00079Y-RK; Fri, 15 Aug 2003 07:46:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nd1J-00077r-34 for tsvwg@optimus.ietf.org; Fri, 15 Aug 2003 07:45:25 -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 HAA24889 for <tsvwg@ietf.org>; Fri, 15 Aug 2003 07:45:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nd1I-00020G-00 for tsvwg@ietf.org; Fri, 15 Aug 2003 07:45:24 -0400
Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19nd1H-00020D-00 for tsvwg@ietf.org; Fri, 15 Aug 2003 07:45:23 -0400
Received: by mail.eecis.udel.edu (Postfix, from userid 62) id EA6A0328B8; Fri, 15 Aug 2003 07:45:22 -0400 (EDT)
Received: from louie.udel.edu (louie.udel.edu [128.4.40.12]) by mail.eecis.udel.edu (Postfix) with ESMTP id CEF40328B8; Fri, 15 Aug 2003 07:45:14 -0400 (EDT)
Date: Fri, 15 Aug 2003 07:45:13 -0400
From: Sourabh Ladha <ladha@mail.eecis.udel.edu>
X-X-Sender: <ladha@louie.udel.edu>
To: Mark Allman <mallman@grc.nasa.gov>
Cc: tsvwg@ietf.org, Ethan Blanton <eblanton@cs.purdue.edu>, Reiner Ludwig <Reiner.Ludwig@ericsson.com>
Subject: Re: [Tsvwg] Issues with draft-blanton-dsack-use-02
In-Reply-To: <20030814185946.24C723BB3CD@guns.grc.nasa.gov>
Message-ID: <Pine.GSO.4.33.0308150741280.18512-100000@louie.udel.edu>
X-Spam-Status: No, hits=-5.0 required=6.0 tests=DEPT_RCVD,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43
X-Sanitizer: This message has been sanitized!
X-Sanitizer-URL: http://mailtools.anomy.net/
X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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>

Hi Mark/All,

* In the draft the following is about the SACK scoreboard: "We assume the
TCP sender has a data structure to hold selective acknowledgment
information (e.g., as outlined in [RFC3517])."

Traditionally entries lying below the cumulative ACK point are deleted
from the scoreboard. But the DSACK information normally comes after loss
recovery has exited. So how long should the scoreboard entries be
maintained beyond what is required in 3517? (1 ACK after loss recovery
exits in Fast retransmit; and N Acks after loss recovery exits in a
timeout (GoBackN)?)


* In the Security Considerations, ECN Nonce 3540 is offered as a
protection. But 3540 calls for disabling Nonce Sum checks for DupAcks. Is
the draft suggesting some extension to 3540 that NS be checked for DupAcks
carrying DSACK?

It may be helpful to be more explicit on the above in the ID.


Thanks


On Thu, 14 Aug 2003, Mark Allman wrote:

>
> Folks-
>
> Ethan and I just revised the i-d per the thread on tsvwg over the
> last month.  The two major changes to the document are:
>
>   * if the SACK scoreboard is empty when a DSACK rolls in then we
>     say the TCP cannot revert its congestion control state because
>     the presumption is that all the ACKs have been lost
>
>   * if the TCP ertransmits something more than once then the TCP
>     cannot revert the congestion control state because DSACKs can no
>     longer resolve the retransmission ambiguity
>
> We have sent the new version of the i-d to the archives and so it
> will appear in the standard places in the next few days.  It is
> available at:
>
>  http://roland.grc.nasa.gov/~mallman/papers/draft-ietf-tsvwg-dup-notify-01.txt
>
> now.
>
> We would appreciate comments on the new version.
>
> Thanks,
> allman
>
>
> --
> Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
>
> _______________________________________________
> tsvwg mailing list
> tsvwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg
>


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