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

[Sally Floyd <[e-mail]>]

Lars -

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

Many thanks for the feedback.  I have made the changes (detailed  
feedback
is below), and the revised draft is at:
   http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-06.txt
   http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-06.pdf

I will submit it tomorrow.
(And by Friday I will have the simulation scripts on-line.)

Many thanks,
Sally


The detailed feedback:
> 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.

DONE.

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

Actually, there is some SHOULDs and a MUST in the rest of that
section.  I made sub-sections, to make it more clear.

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

DONE.

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

DONE.

> Or, if NoWaiting is preferred,
>  maybe the Waiting alternative should be moved out of Section 4 and
>  into another Section (this one?)

I did the first 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.

DONE.

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

DONE.

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

I added the URL (and I will add the simulations to the
web page indicated by the URL by Friday...)

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

DONE.  Many thanks.

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm