From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Jan 4 08:32:34 2011 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC5B3A6CE6 for ; Tue, 4 Jan 2011 08:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaOOaLsCLCnc for ; Tue, 4 Jan 2011 08:32:32 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id 631FB3A6C3A for ; Tue, 4 Jan 2011 08:32:32 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id A0AD5633B1; Tue, 4 Jan 2011 17:34:37 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9844B59A8A; Tue, 4 Jan 2011 17:34:37 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org, Michael Welzl , David Ros Date: Tue, 4 Jan 2011 17:34:36 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <20101201003014.AB9443A6BE7@core3.amsl.com> <0EA8160F-FD4C-40F5-ABE4-2958659A6632@ifi.uio.no> <791AD3077F94194BB2BDD13565B6295D86B527@PALLENE.office.hd> In-Reply-To: <791AD3077F94194BB2BDD13565B6295D86B527@PALLENE.office.hd> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201101041734.36287.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: Rolf Winter Subject: Re: [ledbat] New Version Notification for draft-ietf-ledbat-survey-02 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:32:34 -0000 Hi, my points have all be addressed. From my point of view the document is now= =20 much clear.=20 One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'... Some more high level comments: 1) I would like to RAPID Congestion Control in this document because it a n= ew=20 and really different approach in the area of delay-based congestion control. 2) Not sure if section 2.1. is needed at all in this document as these are= =20 general issues about delay measurements and not especially for LBE=20 transports.=20 3) Why is there only a 'potential issues' section (2.2.) for the delay base= d=20 approaches? I would say every approach has its issues, e.g. the non-delay=20 based approaches in section 3. have to send with a certain minimum rate; th= ey=20 will never give all the available capacity to the competing TCP connection.= =20 Application level approach introduce often more overhead and network-assist= ed=20 approaches require the bottleneck to cooperate. 4) In section 5 I suggest to weighted fair queuing. Happy New Year! Mirja On Thursday 16 December 2010 09:55:21 Rolf Winter wrote: > Hi, > > I would also be good if the previous reviewers could assess whether their > comments have been addressed or not. > > Best, > > Rolf > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London > W3 6BL | Registered in England 2832014 > > > -----Original Message----- > > From: ledbat-bounces@ietf.org [mailto:ledbat-bounces@ietf.org] On > > Behalf Of Michael Welzl > > Sent: Donnerstag, 9. Dezember 2010 20:52 > > To: ledbat@ietf.org > > Subject: Re: [ledbat] New Version Notification for draft-ietf-ledbat- > > survey-02 > > > > Hi all, > > > > We still haven't heard back from any volunteers... this isn't a very > > long or complicated document, it would be great to get our third and > > final volunteer to quickly review it. > > > > Cheers, > > Michael > > > > On Dec 1, 2010, at 1:40 AM, David Ros wrote: > > > Dear all, > > > > > > As promised in Beijing, we've posted an update to the survey draft, > > > see announcement below. Comments are welcome. > > > > > > Also, the chairs requested (at least) one more review; please > > > volunteer! > > > > > > Thanks in advance & best regards, > > > > > > David. > > > > > > D=E9but du message r=E9exp=E9di=E9 : > > >> De : IETF I-D Submission Tool > > >> Date : 1 d=E9cembre 2010 01:30:14 HNEC > > >> =C0 : david.ros@telecom-bretagne.eu > > >> Cc : michawe@ifi.uio.no > > >> Objet : New Version Notification for draft-ietf-ledbat-survey-02 > > >> > > >> > > >> A new version of I-D, draft-ietf-ledbat-survey-02.txt has been > > >> successfully submitted by David Ros and posted to the IETF > > >> repository. > > >> > > >> Filename: draft-ietf-ledbat-survey > > >> Revision: 02 > > >> Title: A Survey of Lower-than-Best-Effort Transport > > > > Protocols > > > > >> Creation_date: 2010-12-01 > > >> WG ID: ledbat > > >> Number_of_pages: 17 > > >> > > >> Abstract: > > >> This document provides a survey of transport protocols which are > > >> designed to have a smaller bandwidth and/or delay impact on standard > > >> TCP than standard TCP itself when they share a bottleneck with it. > > >> Such protocols could be used for delay-insensitive "background" > > >> traffic, as they provide what is sometimes called a "less than" (or > > >> "lower than") best-effort service. > > >> > > >> > > >> > > >> The IETF Secretariat. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > David ROS > > > http://www.rennes.enst-bretagne.fr/~dros/ > > > > > > I love deadlines. I like the whooshing sound they make as they fly > > > by. -- Douglas Adams > > > > _______________________________________________ > > ledbat mailing list > > ledbat@ietf.org > > https://www.ietf.org/mailman/listinfo/ledbat > > _______________________________________________ > ledbat mailing list > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Jan 4 08:37:50 2011 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB673A6C16 for ; Tue, 4 Jan 2011 08:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xirralx-sddv for ; Tue, 4 Jan 2011 08:37:49 -0800 (PST) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by core3.amsl.com (Postfix) with ESMTP id D7E0A3A6BC5 for ; Tue, 4 Jan 2011 08:37:48 -0800 (PST) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4EDC8633B1; Tue, 4 Jan 2011 17:39:55 +0100 (CET) Received: from vpn-2-cl177 (vpn-2-cl177 [10.41.21.177]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4703E59A8A; Tue, 4 Jan 2011 17:39:55 +0100 (CET) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: ledbat@ietf.org Date: Tue, 4 Jan 2011 17:39:54 +0100 User-Agent: KMail/1.9.10 (enterprise35 0.20090731.1005176) References: <9FF43AB0-FA71-4536-ADE7-78CA2CEEEF12@ifi.uio.no> In-Reply-To: <9FF43AB0-FA71-4536-ADE7-78CA2CEEEF12@ifi.uio.no> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201101041739.54383.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [ledbat] draft-ietf-ledbat-survey-03.txt X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 16:37:50 -0000 Hi Michael, from my point of there does not need to be a comparison with only LEDBAT. F= or=20 me it would be okay to have the pro's and con's for every approach in=20 relation to each other or with a general point of view. But I would like to= =20 see a really short discussion for every approach that gives the reader a=20 change to get a first impression in which cases which mechanism can be used= =20 or should not be used. Mirja=20 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 > ledbat@ietf.org > https://www.ietf.org/mailman/listinfo/ledbat =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From michawe@ifi.uio.no Fri Jan 14 08:34:36 2011 Return-Path: X-Original-To: ledbat@core3.amsl.com Delivered-To: ledbat@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7A13A6BAB for ; Fri, 14 Jan 2011 08:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj0uNkTLOZ4Y for ; Fri, 14 Jan 2011 08:34:34 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id D72F13A6B9A for ; Fri, 14 Jan 2011 08:34:33 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Pdme2-0000VK-Oh for ledbat@ietf.org; Fri, 14 Jan 2011 17:36:58 +0100 Received: from 1x-193-157-203-179.uio.no ([193.157.203.179]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Pdme2-0004MO-3c for ledbat@ietf.org; Fri, 14 Jan 2011 17:36:58 +0100 From: michawe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 17:36:57 +0100 Message-Id: <4BDBB5BF-2D33-44E6-91C9-F6541E7E0684@ifi.uio.no> To: ledbat@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 2 total rcpts 5550 max rcpts/h 33 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D231D75B6F38D5780B13F398E6207F519EAA11D2 X-UiO-SPAM-Test: remote_host: 193.157.203.179 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 33 max/h 5 blacklist 0 greylist 0 ratelimit 0 Subject: [ledbat] draft-ietf-ledbat-survey-04 X-BeenThere: ledbat@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list of the LEDBAT WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:34:36 -0000 Hi, We have updated our survey draft, which is now available from here: http://www.ietf.org/id/draft-ietf-ledbat-survey-04.txt Please find our answers to the remaining reviewer comments (just Mirja, = unless we missed something). Reviewers, please let us know if you think = that we addressed your comments now, or if you require further changes. = Thanks! Cheers, Michael ----- todo list: One small thing: NF-TCP is not introduced as 'Network-Friendly TCP'... -- Done. Some more high level comments: 1) I would like to RAPID Congestion Control in this document because it = a new=20 and really different approach in the area of delay-based congestion = control. -- We believe that adding a mechanism like RAPID, which was not designed = for LBE but occasionally happens to show this behavior, is opening a can = of worms. For example, in Fig.8 of the Infocom RAPID paper, it looks as = if FAST would then be the next candidate to talk about. Sometimes it may = be LBE - sometimes not. e.g., from our reference [Aru10]: "Fig. 9(a) = illustrates that although NF-TCP has a much shorter RTT, it is friendly = towards TCP flows while also opportunistically utilizing the spare = bandwidth. TCP-LP (Fig. 9(c)) is also friendly to standard TCP, but is = not compeletly submissive. RAPID (Fig. 9(b)) and LEDBAT (Fig. 9(d)) are = both not submissive. For RAPID, this is due to the combination of its = aggressive nature and its complete reliance on delay-based probing to = measure available bandwidth." (a side note: regarding LEDBAT, the authors might have evaluated an old = version, I didn't check) 2) Not sure if section 2.1. is needed at all in this document as these = are=20 general issues about delay measurements and not especially for LBE=20 transports.=20 -- We think it adds value to the document because there is such a weight = on the delay-based side in it. This section is also really only about = measuring delay within a congestion control mechanism, not delay = measurements in general.=20 3) Why is there only a 'potential issues' section (2.2.) for the delay = based=20 approaches? I would say every approach has its issues, e.g. the = non-delay=20 based approaches in section 3. have to send with a certain minimum rate; = they=20 will never give all the available capacity to the competing TCP = connection.=20 Application level approach introduce often more overhead and = network-assisted=20 approaches require the bottleneck to cooperate. -- Similar to the case above, we felt that this adds value because there = is such a weight on the delay-based side in the document. We briefly = addressed the fact that, of course, all approaches have their issues at = the beginning of the respective section. e.g., in section 3, we have the = statement: "such mechanisms likely cause more queuing delay and react to = congestion more slowly than delay-based ones." I could come up with = quite a number of other problems - e.g. corruption loss, etc.; many of = these things are covered in = draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt. We = believe that going into more details on issues of non-delay-based = approaches (enough to justify adding a section of its own) would stretch = this too far and make the document unnecessarily boring and hard to = read. 4) In section 5 I suggest to weighted fair queuing. -- We decide against this because the scope of our document is on = *transport protocols*, i.e. protocols operating at the transport layer, = i.e. protocols involving end systems. Section 5 deals with such = protocols that receive assistance from the network - i.e. there is some = form of design which involves the end systems and the network. This does = not include pure inside-the-network approaches; e.g., RFC 3662 very = explicitly introduces a LBE behavior (and so might a ton of other work, = possibly even from the MPLS world!), but also doesn't fit for the = reasons above. ... from Mirja's second email: from my point of there does not need to be a comparison with only = LEDBAT. For=20 me it would be okay to have the pro's and con's for every approach in=20 relation to each other or with a general point of view. But I would like = to=20 see a really short discussion for every approach that gives the reader a=20= change to get a first impression in which cases which mechanism can be = used=20 or should not be used. -- For LEDBAT, we now added a "Conclusion and LEDBAT considerations" = section. For the rest, we think that we have covered this (short, as you = say) in the first paragraph of every section in the last update.