Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion

From: Rolf Winter <[email-masked]>
Date: Thu, 5 Aug 2010 08:24:48 +0000

Gengyu,

I think I have not answered you yet. Sorry for that, the IETF meeting and all...

To answer your question. In an ideal world LEDBAT would consume 100% of the available bandwidth if no other traffic passes the bottleneck, which we assume to be at the modem in your uplink direction. Once other traffic competes for the bandwidth, LEDBAT would ideally disappear or consume some of the bandwidth in case the extra delay of the other traffic is < 25ms. Now that is the theory, in practice you want to get as close to that behavior as possible. 

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 Gengyu WEI
> Sent: Dienstag, 27. Juli 2010 09:11
> To: Rolf Winter
> Cc: [email-masked]
> Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion
> 
> Rof,
> 
> There is a question.
> 
> What do you mean "saturate the bottleneck" ?
> Does it mean that the bottleneck link utilization is more than 90%, or
> 95%, or even more?
> 
> In the draft,
> 
>  LEDBAT design goals are:
> 
>    1.  saturate the bottleneck
> 
>    2.  keep delay low when no other traffic is present
> 
>      ...
> 
> Regards,
> 
> Gengyu
> 
> ----- Original Message -----
> From: "Rolf Winter" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, July 16, 2010 4:31 PM
> Subject: [ledbat] review of draft-ietf-ledbat-congestion
> 
> 
> > WG,
> >
> > please review draft-ietf-ledbat-congestion, and see if your comments
> have been adequately addressed. If you do not see any issues please
> also speak up. I'd like to get a feeling whether the group thinks the
> draft is done or not.
> >
> > Thanks,
> >
> > Rolf
> >
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> >
> >
> > _______________________________________________
> > ledbat mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ledbat
> >
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

---

From: The 8472 <[email-masked]>
Date: Thu, 05 Aug 2010 13:47:09 +0200

In practice you will probably see that high link utilization at the 
bottleneck would cause AQM algorithms like RED or BLUE to drop packets 
or ECN-mark them, which as far as i understand it would induce TCP-like 
AIMD-see-saw-ing in LEDBAT like you see it in most other congestion 
control algorithms.

On 05.08.2010 10:24, Rolf Winter wrote:
> To answer your question. In an ideal world LEDBAT would consume 100% of the available bandwidth if no other traffic passes the bottleneck, which we assume to be at the modem in your uplink direction. Once other traffic competes for the bandwidth, LEDBAT would ideally disappear or consume some of the bandwidth in case the extra delay of the other traffic is<  25ms. Now that is the theory, in practice you want to get as close to that behavior as possible.
>
> Best,
>
> 	Rolf
>
>
>> From: "Rolf Winter"<[email-masked]>
>> To:<[email-masked]>

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 5 Aug 2010 08:01:54 -0400

>In practice you will probably see that high link utilization at the bottleneck would cause AQM algorithms like RED or BLUE to drop packets or ECN-mark them

Assuming the bottleneck link *has* implemented AQM, which tends not to be the case for many broadband modems for example.

---

From: Rolf Winter <[email-masked]>
Date: Thu, 5 Aug 2010 13:21:45 +0000

Hi,

We have found some modern DSL home gateways to implement some sort of traffic shaping to prioritize predefined traffic types such as VoIP and certain high priority packets (ACKs, ICMP etc.). These actually solve the LEDBAT problem, i.e. with those LEDBAT is not needed any more (if you get the traffic classification right) and you can use TCP for your P2P apps. But as Richard has mentioned, we found none that do RED or ECN marking. But Lars owns a gazillion home gateways and does some test. Hopefully, he'll at some point do some tests to shed more light on this.

Best,

	Rolf

> Behalf Of Woundy, Richard
> Sent: Donnerstag, 5. August 2010 14:02
> To: [email-masked]; Rolf Winter
> Cc: [email-masked]
> or ECN-mark them
> Assuming the bottleneck link *has* implemented AQM, which tends not to
> be the case for many broadband modems for example.
> 
> 
> 
> > To answer your question. In an ideal world LEDBAT would consume 100%
> of the available bandwidth if no other traffic passes the bottleneck,
> which we assume to be at the modem in your uplink direction. Once other
> traffic competes for the bandwidth, LEDBAT would ideally disappear or
> consume some of the bandwidth in case the extra delay of the other
> traffic is<  25ms. Now that is the theory, in practice you want to get
> as close to that behavior as possible.
> >
> > Best,
> >
> > 	Rolf
> >
> >

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 5 Aug 2010 09:36:27 -0400

> But as Richard has mentioned, we found none that do RED or ECN
marking. But Lars owns a gazillion home gateways and does some test.
Hopefully, he'll at some point do some tests to shed more light on this.

>From section 4.3.2 of
http://conferences.sigcomm.org/imc/2007/papers/imc137.pdf:

"We found that 26.2% of the DSL hosts show a RED-style
drop policy on their upstream queues. The three providers
owned by AT&T (i.e., Ameritech, BellSouth, and PacBell)
exhibit deployment rates between 50.3% and 60.5%, whereas
all other DSL providers' deployment rates are below 23.0%.
The partial deployment of RED-style policies within ISPs
could be due to heterogeneity in the ISPs' equipment. We
did not detect RED in any of the cable ISPs measured."

It would be good to see what Lars sees in his lab testing.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rolf Winter
Sent: Thursday, August 05, 2010 9:22 AM
To: Woundy, Richard; [email-masked]
Cc: [email-masked]
Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion

Hi,

We have found some modern DSL home gateways to implement some sort of
traffic shaping to prioritize predefined traffic types such as VoIP and
certain high priority packets (ACKs, ICMP etc.). These actually solve
the LEDBAT problem, i.e. with those LEDBAT is not needed any more (if
you get the traffic classification right) and you can use TCP for your
P2P apps. But as Richard has mentioned, we found none that do RED or ECN
marking. But Lars owns a gazillion home gateways and does some test.
Hopefully, he'll at some point do some tests to shed more light on this.

Best,

	Rolf

> > I think I have not answered you yet. Sorry for that, the IETF
meeting
> and all...

---

From: The 8472 <[email-masked]>
Date: Thu, 05 Aug 2010 16:00:24 +0200

keep in mind that it's not always the modem that's the bottlneck. 
Artificial throttling employed by some ISPs, shared local loops in cable 
networks and other side-effects of overselling available bandwidth can 
cause packet drops too and might include AQM too.

On 05.08.2010 14:01, Woundy, Richard wrote:
> From: [email-masked]<[email-masked]>
> To: Rolf Winter<[email-masked]>
> Cc: [email-masked]<[email-masked]>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 5 Aug 2010 18:26:02 +0200

Hi,

LEDBAT's aim is to avoid queuing delays that means LEDBAT tries to fully 
utilize the capacity but keep the queue empty. Of cause LEDBAT will not be 
able to keep the queue completely empty but the queue length will be 
determined by the TARGET value and the bottleneck bandwidth. Anyway the queue 
length should be smaller than a dropping/marking threshold in a RED router.

Mirja

On Thursday 05 August 2010 13:47:09 The 8472 wrote:
> > To answer your question. In an ideal world LEDBAT would consume 100% of
> > the available bandwidth if no other traffic passes the bottleneck, which
> > we assume to be at the modem in your uplink direction. Once other traffic
> > competes for the bandwidth, LEDBAT would ideally disappear or consume
> > some of the bandwidth in case the extra delay of the other traffic is< 
> > 25ms. Now that is the theory, in practice you want to get as close to
> > that behavior as possible.
> >
> > Best,
> >
> > 	Rolf
> >
> >

-- 
-------------------------------------------------------------------
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: Murari Sridharan <[email-masked]>
Date: Thu, 5 Aug 2010 18:13:35 +0000

Even if AQM support itself is available in silicon, configuring the parameters will still be a pain. Also if you try AQM in places that have low stat mux the link will not be work conserving due to the saw tooth behavior, so unless this is a high stat mux background router chances of AQM being enabled and configured appropriately is low, IMO. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The 8472
Sent: Thursday, August 05, 2010 7:00 AM
To: Woundy, Richard
Cc: [email-masked]; [email-masked]
Subject: Re: [ledbat] review of draft-ietf-ledbat-congestion

keep in mind that it's not always the modem that's the bottlneck. 
Artificial throttling employed by some ISPs, shared local loops in cable networks and other side-effects of overselling available bandwidth can cause packet drops too and might include AQM too.

On 05.08.2010 14:01, Woundy, Richard wrote:
>> bottleneck would cause AQM algorithms like RED or BLUE to drop 
>> packets or ECN-mark them
>>      
> or ECN-mark them, which as far as i understand it would induce 
> TCP-like AIMD-see-saw-ing in LEDBAT like you see it in most other 
> congestion control algorithms.
>
>>> Does it mean that the bottleneck link utilization is more than 90%, 
>>> or 95%, or even more?
>>>
>>> In the draft,
>>>
>>>    LEDBAT design goals are:
>>>
>>> From: "Rolf Winter"<[email-masked]> To:<[email-masked]>

---

From: "Gengyu WEI" <[email-masked]>
Date: Fri, 6 Aug 2010 07:48:47 +0800

Rolf, 

Thank you for your answering.

Is The "<25ms" of the extra delay of the other traffic within one queue? 
How could you know that is significant from the end to end point of view?

Gengyu

----- Original Message ----- 
From: "Rolf Winter" <[email-masked]>
To: "Gengyu WEI" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 05, 2010 4:24 PM
Subject: RE: [ledbat] review of draft-ietf-ledbat-congestion

Gengyu,

Best,

Rolf

---

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 5 Aug 2010 21:37:46 -0700

That's correct.

Even if silicon support is nominally present and configured, with the  
upstream queue sizes seen in the wild, AQM drops should probably not  
kick in when it's just LEDBAT using the link.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

On Aug 5, 2010, at 9:26 AM, Mirja Kuehlewind wrote:

>> packets
>>> meeting and
>>> all...

---

From: Rolf Winter <[email-masked]>
Date: Fri, 6 Aug 2010 07:17:52 +0000

Gengyu,

This is not based on a single queue but on the one-way delay as described in the draft. The 25ms extra delay are based on the lowest one-way delay observed in a certain time period. Assuming that all factors that contribute to delay (such as serialization delay) are fairly constant, all the difference you will see is coming from queuing delay as the only variable component in the end-to-end delay. But this is fairly well explained in the draft.

Best,

	Rolf

> From: Gengyu WEI [mailto:[email-masked]]
> Sent: Freitag, 6. August 2010 01:49
> To: Rolf Winter
> Cc: [email-masked]
> the available bandwidth if no other traffic passes the bottleneck,
> traffic is < 25ms. Now that is the theory, in practice you want to get
> or

---

From: Joe Touch <[email-masked]>
Date: Fri, 06 Aug 2010 15:32:58 -0700

On 8/5/2010 9:26 AM, Mirja Kuehlewind wrote:
> utilize the capacity but keep the queue empty.

If that's the case, we should be talking about bottlenecks (plural). 
There are two such cases: striped paths (parallel links), and cascaded 
links in which we compete for resources on each cascade.

IMO, our goal is:

on any link where we present more capacity than that link can carry, we 
should consume 100% of the available capacity of that link

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 10 Aug 2010 16:51:27 +0200

Not sure about that. First of all we want to design a Low Extra Delay 
Background Transport that means back off early if other traffic arises and 
keep the queues as empty as possible.

To utilize the available capacity is 'just' another thing that is valuable to 
keep the transport running.

If utilization is the first goal, we should probably switch to a mechanism 
like RAPID [1].

Mirja

[1] V. Konda and 1. Kaur, "RAPID: Shrinking the Congestion-Control
Timescale:' in Proc. INFOCOM 2009, 19-25 April 2009, pp. 1-9.