Subject: [ledbat] draft-ietf-ledbat-survey-03.txt

From: Michael Welzl <[email-masked]>
Date: Fri, 17 Dec 2010 22:02:51 +0100

Hi all,

We have now submitted draft-ietf-ledbat-survey-03.txt, in which we  
tried to address Wes' comments:
http://www.ietf.org/id/draft-ietf-ledbat-survey-03.txt
See below for his list of comments, with our answers in line.

We would like to raise a question to the chairs regarding one matter.  
Wes, and Mirja before him, have suggested to include a concluding  
section where we discuss pro's and con's of LEDBAT in comparison to  
the related work here. It seems clear to us that such a section would  
not make any sense without citing the LEDBAT document, but such a  
citation would put this document on hold until LEDBAT is published. It  
seems to us that this just goes to show that this is in fact the wrong  
sequence, and the wrong place for this discussion: in our opinion, the  
LEDBAT document should contain a short paragraph where it is explained  
how it relates to the state of the art, as documented in our survey.  
This would seem like a much nicer structure to us (e.g. in academia,  
first you look at the state of the art, then you propose your  
mechanism in relation to it).

We would appreciate if the chairs could let us know what they think  
about this matter, and if the reviewers could let us know if they are  
happy with how we addressed all their other comments.

Thanks!!

Michael and David

----

ANSWERS TO WES' COMMENTS:

Here are some review comments I had.  Aside from some general ones,  
they're all editorial or possibly minor technical clarifications that  
could be made.

General / Overall

- We should have some material early on to set context; things to  
mention include:
- intended audience (familiarity with standard TCP, RFC2581/5681, is  
assumed)
- this was a product of the LEDBAT WG for comparison/contrast to the  
chosen approach (this needs to be mentioned, because remember that  
when the RFC is published, a casual reader won't know it came from  
LEDBAT unless you say so)
- most techniques discussed here are tested in limited simulations or  
experimental testbeds, but LEDBAT's algorithm is already under  
widespread deployment (i.e. we need to say that we're acknowledging  
other techniques, but not advocating them here; this does not  
interfere with advancement of the LEDBAT algorithm)
- this is not exhaustive; that wouldn't be possible or useful, but the  
authors/editors have selected key, well-known, or otherwise  
interesting techniques for inclusion at their discretion
- was applicability to big-I Internet deployment scenarios a  
consideration?  (I think yes, but don't actually know in some of the  
cases)

Done. Regarding the "big-I" question, it is clear that almost all of  
the presented mechanisms were designed for that; if there are one or  
two exceptions, then stressing that here just for these mechanisms  
would not contribute much to readability, we believe - the general  
picture, as presented and introduced here, is about the Internet,  
throughout the document.

- Does it need to be more clearly mentioned which classes of  
approaches were mechanisms incorporated in TCP, TCP-alternatives (e.g.  
for DCCP or new transports), or other designs entirely.  For instance,  
do they have subtle (or obvious) differences in the services provided  
to applications (reliability, smoothness, etc.)?  Section 4's first  
paragraph does a good job of explaining this, but other sections had  
me wondering slightly.  It may be a personal problem on my part, so it  
would be good to check with others :).

We tried to state whether mechanisms are incorporated in TCP or  
entirely new protocols upon their appearance in our document (as you  
mention below, we have failed to make this clear enough in section 5,  
but this has now been fixed). Generally, the new protocol / TCP-change  
classification is orthogonal to ours, i.e. both variants are scattered  
throughout the document. Regarding the service provided to  
applications, there is no simple answer here. LBE is, as we define, "a  
service which results in smaller bandwidth and/or delay impact on  
standard TCP than standard TCP itself, when sharing a bottleneck with  
it". This is fairly network-centric; a more user-centric perspective  
is not commonly taken in this literature, and no user-centric  
comparison exists to the best of our knowledge. Yet, the user  
experience will be different, depending on the dynamics of the  
underlying mechanism -- much like you could get a different user  
experience from CTCP, HTCP and CUBIC.

- Are there fairly common assumptions in a lot of the existing  
academic analysis cited here which influence results?  For instance,  
there are often assumptions about flow length, RTT distributions, or  
other elements that may be relevant to mention here? (e.g. all flows  
are FTP of 10 GB files, etc.)

We think not.

- Should there be a (very short) conclusions section that says where  
LEDBAT fits in and the main pros/cons versus the other classes of  
system discussed?

Maybe; this was also requested by Mirja. See our question to the  
chairs regarding this matter.

Section 1

- (editorial) It might be more clear to replace "end-to-end  
mechanisms" with "end-host mechanisms", since end-to-end is relative.

Done.

- (editorial) The LBE acronymn is defined twice in the first  
paragraph; the second expansion at the end of the paragraph can  
probably either just use "LBE" or put the expansion in quotation marks.

Done (just used "LBE").

Section 2

- (editorial) The second sentence of the first paragraph could be  
clarified and shortened to just "Without ECN support, standard TCP  
will normally increase its congestion window (and effective sending  
rate) until a queue overflows, causing one or more packets to be  
dropped and the effective rate to be reduced."  I didn't like the "for  
some reason" in the current sentence because there are clear reasons  
like application limited, advertised receive window limited, kernel  
knob limited, etc, but they all seem to be beside the point rather  
than contributing to it.

Done.

- (editorial) At one point the text capitalizes "Congestion  
Avoidance", and in others it doesn't.  I think lower-case is best.

Done.

- (editorial) "threshold beta" might be more clear as "threshold  
(called "beta")" (same comment applies for alpha)

Done (but without brackets because they don't go well with another  
bracket in the "alpha" part).

- (minor) "actual (measured) throughput" might be more clear as  
"actual throughput measured by recent acknowledgements"

Done.

- (minor) is the increase at the end of the 3rd paragraph every RTT or  
BaseRTT (I don't recall myself)

We checked: the original [Bra94] paper only talks about increasing  
linearly and decreasing linearly. I have therefore removed the "by one  
segment per RTT" bit.

- (minor) "maintaining the window size" should be "maintaining the  
current congestion window"

Done.

- (editorial) "it the standard" should be "it in the standard"

Done.

- (minor) What does "remain transparent to standard TCP" really mean?  
There must be a better way to word this.

Here, it means "avoid interfering with standard TCP traffic", and  
that's what we've now written there.

Section 2.1

- (minor) under the "RTT measurement issues", is it worth mentioning  
the case of fast or short-distance links where the delay is all in the  
stack and not on the wire?

Absolutely! I am surprised that we missed this, thanks for catching  
it! I put that there, now.

Section 2.2

- (minor) is it worth mentioning LEDBAT's sensitivity to changes in  
the route also, when we mention Vegas?  Is it purposeful that we never  
really compare/contrast to LEDBAT itself in this document?

Yes, this might be worth mentioning regarding LEDBAT, but rather than  
scattering LEDBAT comments throughout the document, we have opted for  
putting all such LEDBAT (except for the introductory statement that  
you suggested) in a "Conclusion and relationship to LEDBAT" section if  
we indeed end up writing one (see our question to the chairs).

Section 4

- (editorial) In the last paragraph, is a ":" really the best way to  
punctuate this?

Done.

Section 5

- (minor) For the network-assisted approaches, it wasn't entirely  
clear to me if these were new transport protocols or new mechanisms  
for existing transports; if that could be clarified without the reader  
needing to check the references, I think that would be good.

Done (clarified for every reference where it occurs).

- (minor) Should there be a summary/conclusion sentence here about the  
current viability of such approaches?

We think not, as these proposals are so heterogeneous: e.g., one  
involves changing TCP's AIMD parameters, the other involves no changes  
to TCP at all but essentially putting a multipath-LBE-PEP in the  
network. Anyway, as you said, we're acknowledging other techniques,  
but not advocating them here; we would prefer to present them as  
neutrally as possible.

---

From: Rolf Winter <[email-masked]>
Date: Tue, 21 Dec 2010 15:03:33 +0000

Micheal,

you say that the order is wrong, however, when you look at our original charter, the last item to finish actually is the LEDBAT survey. So the request that both Wes and Mirja have made make complete sense to me. You can already write that section now as I do not see a reason why you would need to wait. 

Best,

	Rolf

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Welzl
> Sent: Freitag, 17. Dezember 2010 22:03
> To: [email-masked]
> Subject: [ledbat] draft-ietf-ledbat-survey-03.txt
> 
> Hi all,
> 
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

---

From: [email-masked]
Date: Tue, 21 Dec 2010 22:19:53 +0100

ok!

> Micheal,
>
> you say that the order is wrong, however, when you look at our original
> charter, the last item to finish actually is the LEDBAT survey. So the
> request that both Wes and Mirja have made make complete sense to me. You
> can already write that section now as I do not see a reason why you would
> need to wait.
>
> Best,
>
> 	Rolf
>
>