Subject: tsv-dir review of draft-ietf-dccp-tfrc-rtt-option-05.txt

From: Mark Allman <[email-masked]>
Date: Mon, 28 Mar 2011 16:37:42 -0400

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review. 

This draft is (I suppose) ready for publication as a Proposed Standard
RFC.  (That is, technically, there is nothing wrong with this document,
but see below.)

I am not in general a fan of stopping documents that get through WGLC
and IETF Last Call for anything but technical issues.  But, this
document does give me pause because it is poorly written and in general
hard to read.  Plus, the motivation seems quite lacking to me.

  - The document is very difficult to read because of all the very
    specific references to some section of some RFC.  Even to specific
    tables.  Hell, even to particular erratas.  The way this document
    reads these are not merely cites to he original material, but the
    reader really has to go and look up all this stuff because this
    document largely doesn't even have hints at what the reference has
    to say.  This style makes the current document very obtuse.

  - The case for sender-side RTTs is not well made.  It is "well, we
    work with this stuff and we have tripped on things" but we have no
    idea if these things happen when Neptune and Venue align or 68 times
    a second.  For all the talk of the experience with the protocol,
    very little of it is actually spelled out in a useful way.

  - In particular, the intro to section 2 is ... well ... odd.  The
    section is called "Problems caused by sampling the RTT at the
    receiver", but as best as I can tell the list at the beginning of
    section 2 encompasses places where an RTT sample is **used** and
    does not describe **problems** with the receiver-based estimation.

  - Section 2.1 is a little better.  It does an OK job of explaining
    *possible* problems with receiver-side estimation.  But, given that
    the section has "real implementation" in the title I expected a
    little more than a textbook examination of possible issues.  I still
    have no idea how big or small these issues might be.  Are they
    corner cases?  Or, big deals?

  - All that said, the spec itself is fine and workmanlike.  The format
    and interactions are well described.

  - In thinking about it, I cannot construct any good reason why
    sender-side RTT estimation would be problematic.

So, in sum, I find the document to be OK technically---even if perhaps a
solution in search of a problem---but the document itself is of fairly
poor quality, IMO.

allman