Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-survey-01

From: David Ros <[email-masked]>
Date: Sat, 9 Oct 2010 02:59:15 +0200

Dear all,

We've posted an update to the survey draft, see announcement below. Comments are very welcome.

Thanks in advance,

David.

Début du message réexpédié :

> De : IETF I-D Submission Tool <[email-masked]>
> Date : 9 octobre 2010 02:46:22 HAEC
> À : [email-masked]
> Cc : [email-masked]
> Objet : New Version Notification for draft-ietf-ledbat-survey-01 
> 
> 
> A new version of I-D, draft-ietf-ledbat-survey-01.txt has been successfully submitted by David Ros and posted to the IETF repository.
> 
> Filename:	 draft-ietf-ledbat-survey
> Revision:	 01
> Title:		 A Survey of Lower-than-Best-Effort Transport Protocols
> Creation_date:	 2010-10-09
> WG ID:		 ledbat
> Number_of_pages: 16
> 
> 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 low-priority "background" traffic,
> as they provide what is sometimes called a "less than" (or "lower
> than") best-effort service.
> 
> 
> 
> The IETF Secretariat.
> 
> 

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

---

From: Rolf Winter <[email-masked]>
Date: Wed, 13 Oct 2010 18:37:51 +0000

Hi,

as mentioned earlier, I would like to have at least 3 people from the group that agree to do a thorough review of this draft (well written, reasonably complete, correct etc). Volunteers please speak up! A lot of people on the list have been working in this field and should be able to do this easily e.g. Mirja, Dario and others.

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 David Ros
> Sent: Samstag, 9. Oktober 2010 02:59
> To: [email-masked]
> Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-
> survey-01
> 
> Dear all,
> 
> > A new version of I-D, draft-ietf-ledbat-survey-01.txt has been
> successfully submitted by David Ros and posted to the IETF repository.
> >
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Oct 2010 23:04:08 +0200

Yes, I will make a review. And I recommend as well to include RAPID.

Mirja

On Wednesday 13 October 2010 20:37:51 Rolf Winter wrote:
> Hi,
>
> as mentioned earlier, I would like to have at least 3 people from the group
> that agree to do a thorough review of this draft (well written, reasonably
> complete, correct etc). Volunteers please speak up! A lot of people on the
> list have been working in this field and should be able to do this easily
> e.g. Mirja, Dario and others.
>
> Best,
>
> 	Rolf
>
>
> > > Title:		 A Survey of Lower-than-Best-Effort Transport
> >
> > Protocols
> >

-- 
-------------------------------------------------------------------
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: [email-masked]
Date: Wed, 13 Oct 2010 23:08:58 +0200

Thank you very much!

About RAPID, see my previous response on the issue - we're considering it.

Cheers,
Michael

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

---

From: "Mayutan A." <[email-masked]>
Date: Thu, 14 Oct 2010 07:46:11 +0200

I have been working on this topic too and will review this document.

Mayutan

On Wed, Oct 13, 2010 at 8:37 PM, Rolf Winter <[email-masked]> wrote:

> > http://www.rennes.enst-bretagne.fr/~dros/<http://www.rennes.enst-bretagne.fr/%7Edros/>
> >

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

---

From: Michael Welzl <[email-masked]>
Date: Thu, 14 Oct 2010 09:59:41 +0200

great! thank you so much!

On Oct 14, 2010, at 7:46 AM, Mayutan A. wrote:

> as mentioned earlier, I would like to have at least 3 people from  
> the group that agree to do a thorough review of this draft (well  
> written, reasonably complete, correct etc). Volunteers please speak  
> up! A lot of people on the list have been working in this field and  
> should be able to do this easily e.g. Mirja, Dario and others.
>
> Best,
>
>        Rolf
>
>
> London W3 6BL | Registered in England 2832014
>
>
> > I love deadlines. I like the whooshing sound they make as they fly  
> by.
> > -- Douglas Adams
> >
> >
> >
> >

---

From: David Ros <[email-masked]>
Date: Thu, 14 Oct 2010 10:14:55 +0200

Hi all,

Thanks a lot to Mirja and Mayutan for volunteering!

Hoping to seeing you in Beijing,

David.

---

From: "Mayutan A." <[email-masked]>
Date: Fri, 15 Oct 2010 15:56:05 +0200

Hi all,

I have finished a round of reviewing and here are my comments:

Overall, the document does not compare the goals of the LEDBAT WG to the
state of the art. Therefore it is very difficult to identify with
the pros and cons of the mentioned approaches. Moreover, it is difficult to
see why LEDBAT was developed instead of
using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a neutral
approach by just mentioning the existing approaches, and leaves it to the
readers to figure out what LEDBAT is trying to do differently. My apologies
in case I missed out on the early discussions where such a decision was
taken.

Some minor comments:

1) Abstract: I am not comfortable with the usage of the term
"low-prioritybackground traffic". It
might be better to use a term that is consistent with the ledbat-congestion
control draft
and the terms used in the LEDBAT WG. The LEDBAT WG,
describes applications such as VoIP as delay-sensitive, therefore it might
be appropriate to use the term delay-insensitive.  Or
 use the term "less-than-best-effort "background" transmissions", to be
consistent with the LEDBAT WG charter.

2) TCP vegas: The draft states that
"TCP Vegas [Bra+94] is one of the first protocols that was known to

   have a smaller sending rate than standard TCP when both protocols
   share a bottleneck [Kur+00] -- yet it was designed to achieve more,
   not less throughput than standard TCP.  "

2.a ) What is the point of this statement? Does it imply that it is not a

good candidate for a LEDBAT like protocol?

   "Indeed, when it is the only

   protocol on the bottleneck, the throughput of TCP Vegas is greater
   than the throughput of standard TCP. "

2.b) Again does this statement imply that it is not a good candidate
for a LEDBAT

like approach?

   Depending on the bottleneck
   queue length, TCP Vegas itself can be starved by standard TCP flows.
   This can be remedied to some degree by the RED Active Queue

 Management mechanism [RFC2309]."
2.c) Is TCP Vegas being starved a positive or a negative with regards to
the goals of the LEDBAT WG?

3) In Section-2, 5th para, TCP-LP and TCP-Nice are mentioned. In the same
para, there is an additional line about TCP-LP. The next para (6th para)
talks about
TCP-Nice and then the 7th para onwards the draft talks about TCP-LP. This is
a bit confusing.
I suggest that it is reorganized it a bit.

4) Section -2, 8th Para: The draft states:
"Regarding its reaction to an early congestion indication, TCP-LP

   tries to strike a middle ground between the overly conservative
   choice of immediately setting the congestion window to one packet and
   the presumably too aggressive choice of halving the congestion window

like standard TCP."

Why does the draft state that TCP-LP takes a middle ground approach. TCP-LP
also reduces its congestion window by half, similar to TCP.

5) Section 3: How is MulTCP a candidate for LEDBAT like approach if it tries
to be as friendly as N TCP flows (where N is greater than or equal to 1)?

6) In section 4: It would be nice to mention some of the
advantages/disadvantages of an application layer approach.

Mayutan

On Thu, Oct 14, 2010 at 10:14 AM, David Ros
<[email-masked]>wrote:

> > as mentioned earlier, I would like to have at least 3 people from the
> group that agree to do a thorough review of this draft (well written,
> reasonably complete, correct etc). Volunteers please speak up! A lot of
> people on the list have been working in this field and should be able to do
> this easily e.g. Mirja, Dario and others.
> >
> > Best,
> >
> >       Rolf
> >
> >
> ============================== ===================================
> David ROS

---

From: David Ros <[email-masked]>
Date: Mon, 18 Oct 2010 22:33:38 +0200

Hi,

Mayutan, thanks a lot for the review. Comments inline...

> Overall, the document does not compare the goals of the LEDBAT WG to the state of the art. Therefore it is very difficult to identify with 
> the pros and cons of the mentioned approaches. Moreover, it is difficult to see why LEDBAT was developed instead of 
> using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a neutral approach by just mentioning the existing approaches, and leaves it to the readers to figure out what LEDBAT is trying to do differently. My apologies in case I missed out on the early discussions where such a decision was taken. 

I'm myself a latecomer (LEDBAT pun intended) to this draft, thus, I may have missed some old discussions; I'll let Michael chime in if needed. However, AFAIK such a discussion never took place, so the draft has adopted a neutral stance. The point of the document, it seems to us, is to show that LEDBAT is not the only existing algorithm and that there are other related approaches out there.

> Some minor comments:
> 
> 1) Abstract: I am not comfortable with the usage of the term "low-priority background traffic". It 
> might be better to use a term that is consistent with the ledbat-congestion control draft
> describes applications such as VoIP as delay-sensitive, therefore it might be appropriate to use the term delay-insensitive.  Or
>  use the term "less-than-best-effort "background" transmissions", to be consistent with the LEDBAT WG charter. 

We have no particular preference on this, though "low-priority" immediately suggests "LBE service" to us.

=> We have no problem with changing the wording to "delay-insensitive".

> 2.b) Again does this statement imply that it is not a good candidate for a LEDBAT 
> like approach? 
> 

As I said above, the draft takes a neutral stance -- it simply reports some facts about Vegas.

> para, there is an additional line about TCP-LP. The next para (6th para) talks about 
> TCP-Nice and then the 7th para onwards the draft talks about TCP-LP. This is a bit confusing. 

Thanks for the suggestion, we'll do it.

> also reduces its congestion window by half, similar to TCP.  

My understanding of TCP-LP is as follows, please feel free to correct me.

When receiving the first early congestion indication, TCP-LP does indeed halve the window, as you say. Then it starts a so-called "inference timer" (the authors suggest setting such timer to 3 RTTs). If in the next RTT there's yet another early congestion indication, and the inference timer has not expired, then the window is set to 1.

So the "middle ground" is between *immediately* decreasing the window to 1 and simply halving it, like plain TCP; they try to delay the former action by an additional RTT, to see if there is persistent congestion or not.

=> There's perhaps a wording issue here (BTW, the authors of TCP-LP employ some similar terms -- they talk about a "compromise"). We may try to explain this a little better.

>  5) Section 3: How is MulTCP a candidate for LEDBAT like approach if it tries to be as friendly as N TCP flows (where N is greater than or equal to 1)? 

This is Michael being too modest about his own work :-). You are right, the focus here should be on MulTFRC, since it can use an N between 0 and 1. However, by allowing N < 1 MulTFRC takes one basic idea of MulTCP a step further, so MulTCP & similar approaches should perhaps be mentioned but, clearly, *not* suggesting that they are somehow an alternative for an LBE transport.

=> Thanks for the remark, we'll try to make this clearer.

>  
> 6) In section 4: It would be nice to mention some of the advantages/disadvantages of an application layer approach. 
> 

Thanks for the suggestion, we'll do it.

Again, thanks a lot for the remarks!

David.

> Mayutan
>  
> 
> On Thu, Oct 14, 2010 at 10:14 AM, David Ros <[email-masked]> wrote:
> Hi all,
>

---

From: "Mayutan A." <[email-masked]>
Date: Thu, 28 Oct 2010 16:49:39 +0200

Hi David,

Sorry for the delay in replying, was held up with another deadline. See
inline for comments:

On Mon, Oct 18, 2010 at 10:33 PM, David Ros
<[email-masked]>wrote:

> > the pros and cons of the mentioned approaches. Moreover, it is difficult
> to see why LEDBAT was developed instead of
> > using TCP-Vegas, TCP-LP and etc. I feel that the draft is taking a
> neutral approach by just mentioning the existing approaches, and leaves it
> to the readers to figure out what LEDBAT is trying to do differently. My
> apologies in case I missed out on the early discussions where such a
> decision was taken.
>
> I'm myself a latecomer (LEDBAT pun intended) to this draft, thus, I may
> have missed some old discussions; I'll let Michael chime in if needed.
> However, AFAIK such a discussion never took place, so the draft has adopted
> a neutral stance. The point of the document, it seems to us, is to show that
> LEDBAT is not the only existing algorithm and that there are other related
> approaches out there.
>
>
It would still be nice to see come comparison to LEDBAT congestion control,
and to state the features that LEDBAT CC borrows from existing approaches.
If not, the draft should atleast state the pros and cons of the approaches,
else it is difficult to understand the need for LEDBAT CC when there are
many existing approaches. I am not sure if this fits in the survey draft or
the LEDBAT congestion control draft. The motivation behind developing LEDBAT
CC as an alternate to all the existing approaches must be documented in one
of the two drafts, preferably in the survey draft.

> "low-priority background traffic". It
> > describes applications such as VoIP as delay-sensitive, therefore it
> might be appropriate to use the term delay-insensitive.  Or
> When receiving the first early congestion indication, TCP-LP does indeed
> halve the window, as you say. Then it starts a so-called "inference timer"
> (the authors suggest setting such timer to 3 RTTs). If in the next RTT
> there's yet another early congestion indication, and the inference timer has
> not expired, then the window is set to 1.
>
> Right. This is how I have understood it too.

> So the "middle ground" is between *immediately* decreasing the window to 1
> and simply halving it, like plain TCP; they try to delay the former action
> by an additional RTT, to see if there is persistent congestion or not.
>
=> There's perhaps a wording issue here (BTW, the authors of TCP-LP employ
> some similar terms -- they talk about a "compromise"). We may try to explain
> this a little better.
>
> The term "middle ground" was confusing since in the first RTT TCP-LP halves
its window similar to TCP. But it makes sense when you consider the protocol
behaviour over a couple of RTTs, wherein TCP-LP cwnd either goes to 1 or
remains at half.

>
> >  5) Section 3: How is MulTCP a candidate for LEDBAT like approach if it
> tries to be as friendly as N TCP flows (where N is greater than or equal to
> 1)?
>
> This is Michael being too modest about his own work :-). You are right, the
> focus here should be on MulTFRC, since it can use an N between 0 and 1.
> However, by allowing N < 1 MulTFRC takes one basic idea of MulTCP a step
> further, so MulTCP & similar approaches should perhaps be mentioned but,
> clearly, *not* suggesting that they are somehow an alternative for an LBE
> transport.
>
> You could probably rewrite it as above. That makes it clear that MulTFRC is
a good candidate for LEDBAT and that it is based on MulTCP.

Cheers,
Mayutan

---

From: Michael Welzl <[email-masked]>
Date: Thu, 28 Oct 2010 17:38:52 +0200

Hi Mayutan!

Thanks for your comments! I leave the others for David, but just this  
one I want to comment on:

> It would still be nice to see come comparison to LEDBAT congestion  
> control, and to state the features that LEDBAT CC borrows from  
> existing approaches. If not, the draft should atleast state the pros  
> and cons of the approaches, else it is difficult to understand the  
> need for LEDBAT CC when there are many existing approaches. I am not  
> sure if this fits in the survey draft or the LEDBAT congestion  
> control draft. The motivation behind developing LEDBAT CC as an  
> alternate to all the existing approaches must be documented in one  

I agree that this would make sense if we would now be at a different  
point in history. That is, if this discussion would take place a few  
years ago, there was no LEDBAT CC mechanism yet, and the survey would  
form the basis for developing LEDBAT, then I would agree.

But this is not how things happened: I was just about to finish the  
first version of the draft (and I was fast with it!) when the LEDBAT  
CC mechanism was presented... I agree that it would be nice to see  
"the motivation behind developing LEDBAT CC as an alternate to all the  
existing approaches", but honestly I have no clue what this motivation  
was (well: my educated guess is that Stas had good real life  
experiences with this scheme, and no real reason to fool around with  
the others, but that isn't appropriate text for the draft I guess). If  
Stas could provide a better explanation of his motivations to develop  
LEDBAT as opposed to picking one of the existing alternatives, this  
would be nice, I think - but since our draft doesn't (and, I think,  
shouldn't) describe LEDBAT but everything else, I really think that  
such a paragraph would better fit in the LEDBAT CC draft.

To conclude: the survey draft is not, and has never been, a basis for  
developing LEDBAT, and therefore its only purpose can be to inform  
people about other stuff that exists out there. I think that this is  
valuable, but in this context it's probably inappropriate to discuss  
pro's and con's which really can't be given without making the  
discussion biased. Since most mechanisms essentially share the exact  
same goal of being inobtrusive, this is a bit like asking for a pros  
and cons discussion of CUBIC vs HTCP vs CTCP vs ....    - where there  
is no simple answer, and upon digging through the authors' papers, you  
would just find that certain mechanisms have been found to be better  
than others under certain circumstances.

Cheers,
Michael

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 Oct 2010 17:49:35 +0200

Hi Micheal,

> than others under certain circumstances.

We are not asking you to answer the question what is the best choice or to 
give a ranking but you can still list the positive and negative points about 
the separate approaches, e.g. approaches based on OWD instead of RTT are more 
accurate because they don't react wrongly in congestion on the return link 
but harder to implement because of receiver-side involvement....

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Thu, 28 Oct 2010 17:58:25 +0200

> but harder to implement because of receiver-side involvement....

oh, ok! that's different; that can be done.

thanks!

michael

---

From: "Mayutan A." <[email-masked]>
Date: Thu, 28 Oct 2010 20:45:25 +0200

> oh, ok! that's different; that can be done.
Great.

---

From: David Ros <[email-masked]>
Date: Fri, 29 Oct 2010 10:48:22 +0200

Hi Mayutan,

My answers inline...

> The term "middle ground" was confusing since in the first RTT TCP-LP halves its window similar to TCP. But it makes sense when you consider the protocol behaviour over a couple of RTTs, wherein TCP-LP cwnd either goes to 1 or remains at half.  

OK, we'll try to rephrase this to make it clearer, by better explaining this behavior-over-several-RTTs stuff. Thanks for the suggestion.

> You could probably rewrite it as above. That makes it clear that MulTFRC is a good candidate for LEDBAT and that it is based on MulTCP. 

Will do.

Thanks!

David.