Subject: [Tsvwg] AD review of draft-ietf-tsvwg-ecn-alternates-00

From: Lars Eggert <[email-masked]>
Date: Wed, 26 Jul 2006 17:52:46 +0200

Hi,

here's the AD review of draft-ietf-tsvwg-ecn-alternates-00 - pretty  
much all minor comments and editorial nits.

Lars

Section 2., paragraph 4:

 >     As an example, in most of the proposals for alternate-ECN  
semantics,
 >     a diffserv field is used to specify the use of alternate-ECN
 >     semantics.  Do all routers that understand this diffserv  
codepoint
 >     understand that it uses alternate-ECN semantics, or not?   
Diffserv
 >     allows routers to re-mark DiffServ Code Point [DSCP] values  
within
 >     the network; what is the effect of this on the alternate-ECN
 >     semantics?

   Nit: Pick a consistent capitalization of diffserv for the whole
   document. (Paragraph above has three variants.)

Section 4.3., paragraph 4:

 >     The only conformant congestion control mechanisms currently
 >     standardized in the IETF are TCP [RFC2581] and protocols using  
TCP-
 >     like congestion control (e.g., SCTP [RFC2960], DCCP with CCID-2
 >     [DCCP]), and TCP-Friendly Rate Control (TFRC) and protocols with

   Add reference to RFC3448.

Section 6., paragraph 1:

 >     There have been a number of proposals in the IETF and in the
 >     research community for alternate semantics for the ECN codepoint
 >     [ECN].  One such proposal, [BCF05], proposes an alternate-ECN
 >     semantics for real-time inelastic traffic such as voice, video
 >     conferencing, and multimedia streaming in DiffServ networks.  In
 >     this proposal, the alternate-ECN semantics would provide  
information
 >     about two levels of congestion experienced along the path  
[BCF05].
 >     Some of the other proposals for alternate ECN semantics are  
listed
 >     on the ECN Web Page [ECN].

   What about [BESFC05]? Also, I think this whole section should be  
moved
   to the introduction.

Section 8., paragraph 1:

 >     This document is based in part on conversations with Jozef  
Babiarz,
 >     Kwok Ho Chan, and Victor Firoiu on their proposal for an  
alternate
 >     use of the ECN field in DiffServ environments.  Many thanks to
 >     Francois Le Faucheur for feedback recommending that the document
 >     include a section at the beginning discussing the potential  
issues
 >     that need to be addressed.  Thanks also to Mark Allman, Fred  
Baker,
 >     David Black, Gorry Fairhurst, and to members of the TSVWG working
 >     group for feedback on these issues.

   Nit: Acknowledgements typically come right before the references.

Section 11., paragraph 2:

 >     [BESFC05] B. Briscoe, P. Eardley, D. Songhurst, F. Le  
Faucheur, A.
 >     Charny, J.  Barbiaz, K. Chan, A Framework for Admission  
Control over
 >     DiffServ using Pre-Congestion Notification, internet-draft draft-
 >     briscoe-tsvwg-cl-architecture-01.txt, work in progress, October
 >     2005.

   Nit: -03 is current.

Section 11., paragraph 3:

 >     [DCCP] DCCP Web Page, URL "http://www.icir.org/kohler/dccp/".

   Replace references to the web site with references to the respective
   DCCP RFCs.

Section 11., paragraph 4:

 >     [ECN] ECN Web Page, URL "www.icir.org/floyd/ecn.html".

   Remove the reference to the web site and replace with reference to
   RFC3168.

Section 11., paragraph 5:

 >     [QuickStart] Quick-Start Web Page, URL
 >     "http://www.icir.org/floyd/quickstart.html".

   Replace with reference to Quickstart ID.

Section 11., paragraph 9:

 >     [RFC3168] Ramakrishnan, K.K., Floyd, S., and Black, D., The  
Addition
 >     of Explicit Congestion Notification (ECN) to IP, RFC 3168,  
Proposed
 >     Standard, September 2001.

   Should be a normative reference.

-- 
Lars Eggert                                     NEC Network Laboratories