Subject: Re: [ledbat] draft-ietf-ledbat-survey-04

From: Michael Welzl <[email-masked]>
Date: Fri, 4 Feb 2011 12:57:52 +1100

Hmmm... silence...

may I ask the reviewers to do a quick check, to see whether there  
comments are now amply addressed or tell us if there's still something  
missing?

Thanks!

Michael

On Jan 15, 2011, at 3:36 AM, michawe wrote:

> 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
> 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
> general issues about delay measurements and not especially for LBE
> transports.
>
> -- 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. 
>
>
> 3) Why is there only a 'potential issues' section (2.2.) for the  
> delay based
> approaches? I would say every approach has its issues, e.g. the non- 
> delay
> based approaches in section 3. have to send with a certain minimum  
> rate; they
> will never give all the available capacity to the competing TCP  
> connection.
> Application level approach introduce often more overhead and network- 
> assisted
> 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
> 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.
>
> -- 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.
>
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 7 Feb 2011 11:17:40 +0100

I'm fine with it.

-- 
-------------------------------------------------------------------
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
-------------------------------------------------------------------

---

From: "Mayutan A." <[email-masked]>
Date: Mon, 7 Feb 2011 11:22:45 +0100

Fine by me.

On Fri, Feb 4, 2011 at 2:57 AM, Michael Welzl <[email-masked]> wrote:

> Hmmm... silence...
>
> may I ask the reviewers to do a quick check, to see whether there comments
> are now amply addressed or tell us if there's still something missing?
>
> Thanks!
>
> Michael
>
>
>
>> 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:
>>
>> 1) I would like to RAPID Congestion Control in this document because it a
>> new
>> -- 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
>> -- 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.
>>
>> 3) Why is there only a 'potential issues' section (2.2.) for the delay
>> based
>> approaches? I would say every approach has its issues, e.g. the non-delay
>> based approaches in section 3. have to send with a certain minimum rate;
>> they
>> Application level approach introduce often more overhead and
>> network-assisted
>> -- 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.
>>
>>
>> *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 my point of there does not need to be a comparison with only LEDBAT.
>> For
>> 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.
>>
>> 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.
>>

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 17 Feb 2011 09:43:29 -0500

> comments are now amply addressed or tell us if there's still something

I checked it over, and it looks good to me.

-- 
Wes Eddy
MTI Systems