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
tsv-dir@xxxxxxxx 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
Attachment:
pgpO7M0XkDN1v.pgp
Description: PGP signature
