[tcpm] AD review: draft-ietf-tcpm-ecnsyn-05

Lars Eggert <lars.eggert@nokia.com> Thu, 13 March 2008 23:39 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4C11E28C7D3; Thu, 13 Mar 2008 16:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.836
X-Spam-Status: No, score=-100.836 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id unkJt5+ahRNA; Thu, 13 Mar 2008 16:39:14 -0700 (PDT)
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id 3F87C28C2ED; Thu, 13 Mar 2008 16:39:14 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id B3FD728C1EE for <tcpm@core3.amsl.com>; Thu, 13 Mar 2008 16:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id dfl4Ny1iacYM for <tcpm@core3.amsl.com>; Thu, 13 Mar 2008 16:39:11 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com []) by core3.amsl.com (Postfix) with ESMTP id 3E1763A6CD5 for <tcpm@ietf.org>; Thu, 13 Mar 2008 16:39:11 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id d11so1097315and.122 for <tcpm@ietf.org>; Thu, 13 Mar 2008 16:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=PWRocUPo5kp/KXZd4uv/bvdHJSwuleEybT0Wlw1vhtM=; b=SRpdW/RJ4MfS1B0J9MBLfuUb1QXhAF/fvAi1k2opwt9Dk8HEURqkuQ5xhJEMgLICJ3ogy+a/niPFv5BIBmhSfj0lJtSznv7O65ceg/S9aXSav8ujKLVRnnL6Jt6tY4fYoaJuIdFtZr0LmcavuPj+BEeu/hKKFvYeeTiizUyUOtw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=uNX1qCMNqs/A28CdwRzltGDFguGsNTwbfos195MRjo9E0ygCdzVMBac87uONXJXhyTF91Bu2Mgw7ND8UP98dE1cdn1WxAF65WGAlbPnnMOtLlQYkUZYLSJUgq8zXNo7xbnpRhl5EOI10hH2tcivMRkPNbjafFnJ7eDdPDeLE4iY=
Received: by with SMTP id r18mr20876294and.112.1205451413421; Thu, 13 Mar 2008 16:36:53 -0700 (PDT)
Received: from ? ( []) by mx.google.com with ESMTPS id c28sm26844525anc.32.2008. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Mar 2008 16:36:53 -0700 (PDT)
Message-Id: <0A9BAFBD-68F2-4EC8-AC86-009905F9F01E@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: mallman@icir.org
In-Reply-To: <20080212040134.0C2093AEC52@lawyers.icir.org>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 13 Mar 2008 19:36:51 -0400
References: <20080212040134.0C2093AEC52@lawyers.icir.org>
X-Mailer: Apple Mail (2.919.2)
Cc: Aleksandar Kuzmanovic <akuzma@northwestern.edu>, tcpm <tcpm@ietf.org>, Ted Faber <faber@isi.edu>, Amit Mondal <a-mondal@northwestern.edu>, "K. K. Ramakrishnan" <kkrama@research.att.com>
Subject: [tcpm] AD review: draft-ietf-tcpm-ecnsyn-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


I did my AD review for draft-ietf-tcpm-ecnsyn-05. Basically, it's good  
to go to IETF last call. There are a few minor suggestions and nits  
below. I'd suggest that we go to IETF Last Call and fix these together  
with any other comments that we receive during the comment period.

(Alternatively, the authors could do another revisions now. Up to you,  
just let me know which way you're going, so I can initiate the last  
call or wait.)


INTRODUCTION, paragraph 13:
 > This document is intended to update RFC 3168.

   s/is intended to update/updates/
   and also add an "Updates: 3168" header to the boilerplate.

Section 3., paragraph 0:
 > 3.  Proposal

     (or Recommendation, but because the text below "only" changes a
     MUST NOT to a MAY, that may be too strong)

Section 3., paragraph 3:
 >    Assume that TCP node A transmits to TCP node B an ECN-setup SYN
 >    packet, indicating willingness to use ECN for this connection.  As
 >    specified by RFC 3168, if TCP node B is willing to use ECN, node B
 >    responds with an ECN-setup SYN-ACK packet.

   Suggestion: Start a new section before this paragraph, because the
   remainder of the original section is more of a description of the
   effects of the change, rather than continuing the specification.

Section 4., paragraph 0:
 > 4.  Discussion

   Nit: Section would be more readable if "Motivation:", "Flooding
   attacks:" etc. became real, numbered subsections. (Same in Section  

Section 6.2., paragraph 2:
 > Simulations comparing the performance with Standard ECN (without ECN-
 > marked SYN/ACK packets), ECN+ with NoWaiting, and ECN+ with Waiting
 > show little difference, in terms of aggregate congestion, between
 > ECN+ with NoWaiting and ECN+ with Waiting.  The details are given in
 > Appendix A below.  Our conclusions are that ECN+ with NoWaiting is
 > perfectly safe, and there are no congestion-related reasons for
 > preferring ECN+ with Waiting over ECN+ with NoWaiting.  That is,
 > there is no need for the TCP end-node to wait a round-trip time
 > before sending a data packet after receiving an acknowledgement of an
 > ECN-marked SYN/ACK packet.

   That recommendation (that NoWaiting is safe and Waiting therefore  
   not be preferred) should also briefly be discussed in Section 4 where
   the approaches are first described. Or, if NoWaiting is preferred,
   maybe the Waiting alternative should be moved out of Section 4 and
   into another Section (this one?)

Section 8., paragraph 2:
 > Future work will address the more general question of adding ECN-
 > Capability to relevant handshake packets in other protocols that use
 > retransmission-based reliability in their setup phase (e.g., SCTP,
 > DCCP, HIP, and the like).

   That work doesn't seem to be happening, so I would suggest to remove
   this section.

Section 100, paragraph 32:
 > Capabililty for SYN/ACK packets, it is possible that the ECN-Capable

   Nit: s/Capabililty/Capability/

Section 100, paragraph 46:
 > [ECN-SYN] ECN-SYN web page with simulation scripts, URL to be added.

   URL needs to be added now.

Section 100, paragraph 60:
 > [SYN-COOK]   Dan J. Bernstein, SYN cookies, 1997, see also
 > <http://cr.yp.to/syncookies.html>

   Might also want to refer to RFC 4987.

tcpm mailing list