[Tsvwg] AD review of draft-ietf-tsvwg-quickstart-05

[Lars Eggert <[e-mail]>]

Hi,

find my review of draft-ietf-tsvwg-quickstart-05 below. I didn't find  
any major technical issues, it's mostly small nits.

One overall meta-comment, however, is that the document mixes  
specification (description of the mechanism and protocols) and  
applicability statements (discussion of behavior, effects, issues,  
plus long appendices discussing related work, design options not  
taken, a rebuttal to a review, etc.) This makes it difficult for the  
reader to extract the mandatory-to-implement pieces out of the  
overall work.

For a Standards Track document, I'd require that this be addressed,  
probably by refactoring the document into multiple smaller and more  
focused ones. Since this is going for Experimental, I'm not going to  
require this, but still would like to strongly suggest that the  
authors discuss whether presenting the large body of work in a small  
number of more focused documents (maybe: architecture, IP-layer  
extension specification, TCP extension specification, applicability  
statement) may not be more readable.

Lars

INTRODUCTION, paragraph 0:

   Document uses "Quick-Start", "Quick Start" and "QuickStart" - choose
   one.


Section 1., paragraph 2:

 >     However, in the case of moderate-sized transfers the connection
 >     might carry out its entire transfer in the slow-start phase,  
taking
 >     many round-trip times, where one or two RTTs might have been
 >     appropriate in the current network conditions.

   I think this should read "...where one or two RTTs might have been
   sufficient when using the currently available bandwidth along the  
path."


Section 2., paragraph 5:

 >     * Any new mechanism must be incrementally deployable, and  
might not
 >     be supported by all of the routers and/or end-hosts.  Thus,  
any new
 >     mechanism must be able to accommodate non-supporting routers  
or end-
 >     hosts without disturbing the current Internet semantics.  We note
 >     that while Quick-Start is incrementally deployable in this  
sense, a
 >     Quick-Start request can not be approved for a particular  
connection

   Nit: s/can not/cannot/


Section 3.4., paragraph 1:

 >     the received Rate Request was in fact less than K.  This  
version of
 >     the nonce is based on a proposal from Guohan Lu [L05].  Initial
 >     versions of this document contained an eight-bit QS Nonce, and
 >     subsequent versions discussed the possibility of a four-bit QS
 >     Nonce.

   May want to move mention of [L05] to the acknowledgment section, and
   remove second part of the paragraph starting with "This version of  
the
   nonce..."


Section 3.4., paragraph 10:

 >     An additional requirement is that the receiver can not be able to

   Nit: s/can not/cannot/


Section 4., paragraph 2:

 >     section.)  When used for initial start-up, the Quick-Start  
request
 >     packet can be either the SYN or SYN/ACK packet, as described  
above.

   Wasn't really described anywhere above, just part of the examples.


Section 4., paragraph 4:

 >     If the acknowledging packet does not contain a Quick-Start  
Response,
 >     or contains a Quick-Start Response with the wrong value for  
the TTL
 >     Diff or the QS Nonce, then host A MUST assume that its Quick- 
Start
 >     request failed.  In this case, host A sends a Report of Approved
 >     Rate with a Rate Report of zero, and uses TCP's default  
congestion
 >     control procedure.  For initial start-up, host A uses the default
 >     initial congestion window [RFC2581].

   Why can't it use large initial windows still?


Section 4., paragraph 5:

 >     In
 >     order to use Quick-Start, the TCP host MUST use rate-based  
pacing to
 >     transmit Quick-Start packets at the rate indicated in the Quick-
 >     Start Response, at the level of granularity possible by the  
sending
 >     host.

   Might want to cite
   http://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.html for rate-based
   pacing.


Section 4.4., paragraph 1:

 >     In addition, if the received Rate Request
 >     is K, then the the rightmost 2K bits of the QS Nonce must match

   Nit: s/the the/the/


Section 4.6.1., paragraph 0:

4.6.1.  Interactions with Path MTU Discovery

   Since draft-ietf-pmtud-method is about to be IETF-last-called, it
   would be good to discuss here how QuickStart interacts with the
   new-style PMTUD, in addition to how it interacts with the old PMTUD
   method.


Section 4.6.1., paragraph 3:

 >     If the sender knows the Path MTU when the initial window is sent
 >     (e.g., from a PMTUD cache or from some other IETF-approved  
method),
 >     then the sender should use that MTU for segments in the initial
 >     window.

   "SHOULD use that MTU"?


Section 4.7., paragraph 6:

 >     (2) Response if Quick-Start packets are dropped:

   Nit: s/(2)/(3)/


Section 10.3., paragraph 1:

 >     Because of possible problems discussed above concerning using  
Quick-
 >     Start over some network paths and the security issues  
discussed in
 >     section 11 , the most realistic initial deployment of Quick-Start

   Nit: s/11 ,/11,/


Section 12., paragraph 0:

12.  IANA Considerations

   Please check draft-narten-iana-considerations-rfc2434bis, Section 5.1
   on how to write this section.


Section 14., paragraph 3:

A.  Related Work

   Since this is already a pretty long draft, is there value in having
   this discussion of related work included here?


Section 14., paragraph 36:

B.  Design Decisions

   Since this is already a pretty long draft, is there value in having
   this discussion included here?


Section 14., paragraph 102:

C.  Quick-Start with DCCP

   Should probably become its own document in the future - needed here?


Section 14., paragraph 113:

D.  Possible Router Algorithm

   Is this redundant, given there is Section 3.3?


Section 14., paragraph 132:

F.  Feedback from Bob Briscoe

   Not sure if a rebuttal to a review is useful to publish as an
   appendix.


Section 14., paragraph 176:

 >     [2401bis] S. Kent and K. Seo, Security Architecture for the  
Internet
 >     Protocol, internet-draft draft-ietf-ipsec-rfc2401bis-06.txt,  
work-
 >     in-progress, March 2005.

   is RFC4301


Section 14., paragraph 178:

 >     [2402bis] S. Kent, IP Authentication Header, internet-draft  
draft-
 >     ietf-ipsec-rfc2402bis-11.txt work-in-progress, March 2005.

   is RFC4302


Section 14., paragraph 184:

 >     [RFC2960] R. Stewart, et. al. Stream Control Transmission  
Protocol.
 >     RFC 2960, October 2000.

   Nit: s/et./et/


Section 14., paragraph 199:

 >     [BJS05] Briscoe, B., Jacquet, A., and A. Salvatori, "Re-ECN:  
Adding
 >     Accountability for Causing Congestion to TCP/IP", internet-draft
 >     draft-briscoe-tsvwg-re-ecn-tcp-00.txt, work-in-progress, October
 >     2005.

   is at -02


Section 14., paragraph 209:

 >     [KHF05] E. Kohler, M. Handley, and S. Floyd, Datagram Congestion
 >     Control Protocol (DCCP), internet draft draft-ietf-dccp- 
spec-11.txt,
 >     work in progress, March 2005.

   is RFC4340


Section 14., paragraph 223:

 >     [SGF05]   Singh, M., Guha, S., and P. Francis, "Utilizing spare
 >     network bandwidth to improve TCP performance", ACM SIGCOMM  
2005 Work
 >     in Progress session , August 2005,

   Nit: s/session ,/session,/


-- 
Lars Eggert                                     NEC Network Laboratories