[tcpm] Some comments on 2581bis

Fernando Gont <fernando@gont.com.ar> Wed, 14 February 2007 07:36 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHEgs-0002iK-VF; Wed, 14 Feb 2007 02:36:34 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHEgr-0002Zl-Dw for tcpm@ietf.org; Wed, 14 Feb 2007 02:36:33 -0500
Received: from smtp1.xmundo.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHEgP-0002ie-JG for tcpm@ietf.org; Wed, 14 Feb 2007 02:36:06 -0500
Received: from venus.xmundo.net (venus.xmundo.net []) by smtp1.xmundo.net (Postfix) with ESMTP id CA326F0C417 for <tcpm@ietf.org>; Wed, 14 Feb 2007 04:35:27 -0300 (ART)
Received: from fgont.gont.com.ar (3-176-231-201.fibertel.com.ar []) (authenticated bits=0) by venus.xmundo.net ( with ESMTP id l1E7ZOPZ017707 for <tcpm@ietf.org>; Wed, 14 Feb 2007 04:35:25 -0300
Message-Id: <200702140735.l1E7ZOPZ017707@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 14 Feb 2007 04:35:19 -0300
To: tcpm@ietf.org
From: Fernando Gont <fernando@gont.com.ar>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (venus.xmundo.net []); Wed, 14 Feb 2007 04:35:26 -0300 (ART)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: [tcpm] Some comments on 2581bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org


Some comments on the draft:

** RFC 2581 & SACK
Page 3 says:
         Alternatively, a TCP that utilizes selective acknowledgments
         [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate"
         if the ACK contains previously unknown SACK information.

And page 7 says:
Note that a sender using SACK [RFC2018]
         MUST NOT send new data unless the incoming duplicate
         acknowledgment contains new SACK information.

IMHO, if you keep the "MUST NOT" in page 7, you'd probably 
s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that 
the SACK information should be "in window"?

** Limits on dupacks
Would it make sense to limit the number of accepted dupacks to 
Max_dupacks = (Flight_size_fr - 1) / SMSS ?
where Flight_size_fr is the Flight_Size at the point fast retransmit 
is triggered.


Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

tcpm mailing list