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

From: Rolf Winter <[email-masked]>
Date: Fri, 18 Mar 2011 07:03:53 +0000

FYI.

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]]
> Sent: Donnerstag, 17. März 2011 23:21
> To: General Area Review Team
> Cc: [email-masked]
> Subject: Gen-art review of draft-ietf-ledbat-survey-05
> 
> 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.