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

[Lars Eggert <[e-mail]>]

Hi,

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.)

Thanks,
Lars


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

   s/Proposal/Specification/
     (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  
7.)


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  
need
   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
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm