Subject: [Gen-art] Gen-art review of draft-ietf-ledbat-survey-05

From: Elwyn Davies <[email-masked]>
Date: Mon, 21 Mar 2011 15:51:50 +0000

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-ledbat-survey-05.txt
Reviewer: Elwyn Davies
Review Date: 17 March 2011
IETF LC End Date:24 March 2011
IESG Telechat date: (if known) -

Summary:  I don't have any major problems with the survey of other work
- I can't say if it is really complete and accurate or deals with the
most relevant poroposals but it seems a good piece of work apart form
one rather cavalier set of statements at the beginning of Section 2.

However there is a bit of a Catch 22:  LEDBAT's own proposal is still a
work in progress but in both sections 1 and 6 there are cryptic
references to its status as a real network deployed mechanism as
compared with the simulations and testbed network deployments used to
characterize the majority of the surveyed, and to the mechanisms which
it uses.  In neither case are any references adduced.  

Clearly there is a problem if the LEDBAT WG want this document published
as an RFC before the LEDBAT mechanism is finalized - referencing the
definitive LEDBAT draft will not be helpful here, but on the other hand
it would be useful either to have some sort of way of (a) justifying the
implicit assumption of LEDBAT's superiority in Section 1 and (b)
pointing to some work that justifies the approach taken in LEDBAT other
than the comparative studies noted (which may not be comparing against
the current LEDBAT proposal as is noted in the draft), or if appropriate
references cannot be found, then adjusting the language to be more
neutral in Section 1 and more explicative in Section 6. 

Major issues:
None

Minor issues:
s2, para 1:
>    In the absence of
>    any other traffic, this is even true for TCP itself when its maximum
>    send window is limited to the bandwidth*round-trip time (RTT)
>    product.
Some evidence for this in the form of a reference would be desirable.

Nits/editorial comments:
s2, para 1: expand ECN.