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

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 4 Jan 2011 17:39:54 +0100

Hi Michael,

from my point of there does not need to be a comparison with only LEDBAT. For 
me it would be okay to have the pro's and con's for every approach in 
relation to each other or with a general point of view. But I would like to 
see a really short discussion for every approach that gives the reader a 
change to get a first impression in which cases which mechanism can be used 
or should not be used.

Mirja 

On Friday 17 December 2010 22:02:51 Michael Welzl wrote:
> 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.
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------