Subject: Re: [ledbat] other open issues

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Jul 2010 18:11:55 +0200

Hi,

> 2. The linear controller that LEDBAT uses suggests that the congestion
> window should be increased proportional to the change in one-way delay.
> This is very good for responding quickly to changes in delay. But this can
> cause the window to increase at a faster rate than TCP would do with its
> probing mechanism using additive-increase. Although the maximum increase in
> window is capped to be less than Best-effort TCP, the rate of increase can
> be more. Does this concern anyone?
I'm not sure if I got you right...  what does "Although the maximum increase 
in window is capped to be less than Best-effort TCP, the rate of increase can
be more." mean? 
Are you saying ledbat can ramp up the cwnd faster than TCP (reno)? This would 
harm one of design goals of ledbat. Is this something specific for your 
implementation or a certain scenario? Or do you have a general case here...?

Mirja

---

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 12 Jul 2010 14:34:43 -0700

On Fri, Jun 11, 2010 at 11:25 AM, Padma Bhooma <[email-masked]> wrote:
> 1. How will base history expire after some idle time? May there should be a recommendation to throw away the history and re-learn delay on the link.

Padma,

Good point, added.

> 2. The linear controller that LEDBAT uses suggests that the congestion window should be increased proportional to the change in one-way delay. This is very good for responding quickly to changes in delay. But this can cause the window to increase at a faster rate than TCP would do with its probing mechanism using additive-increase. Although the maximum increase in window is capped to be less than Best-effort TCP, the rate of increase can be more. Does this concern anyone?

The change is not proportional to the change in one-way delay.

It is proportional to the difference between (non-negative) queuing
delay estimate and the target:

"The maximum speed with which we can increase our congestion window is
then when queuing delay estimate is zero. To be on the safe side,
we'll make this speed equal to how fast TCP increases its sending
speed.  Since queuing delay estimate is always non-negative, this will
ensure never ramping up faster than TCP would."

> Some of these decisions can be made implementation-specific. I think, it will be good if there is some discussion about it.
> Thanks,
> Padma
>
> On Jun 8, 2010, at 12:00 PM, [email-masked] wrote:
>
> Date: Tue, 8 Jun 2010 16:03:37 +0200
> From: "Rolf Winter" <[email-masked]>
> Subject: [ledbat] Open issues, part 1
> To: <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> Here is the first Email in a series of Emails (to keep Email threats separate) which deal with open points in the congestion control draft. I pulled those together from various sources such as meeting minutes. I would like have a documented agreement on them. If there are other open question please speak up.
>
> 1. Parameters
> There were comments on the parameterization of the congestion control draft. The main concern was that they seem to come out of thin air. To close this issue I'd like to ask the group whether they think the parameters are sensible or not (e.g. 25ms delay target). It would be good to hear from people such as, say, game developers what they have to say about this target. A better description of why these were chosen is surely something that should go into the text.
>
> Best,
>
> 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
>

--
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Padma Bhooma <[email-masked]>
Date: Tue, 13 Jul 2010 07:24:39 -0700

Here is how I interpret it:

Let's say one best-effort TCP and one ledbat flow are sharing a link. At some point in time they both have a congestion window of 4 packets each. Assume that LEDBAT measures a difference between queuing delay estimate and the target delay of 10ms. This is the off_target variable in the algorithm and includes the random_input. In the next RTT, the LEDBAT flow will increase its congestion window by 10 packets (total 14 packets). Whereas the best-effort TCP flow will increase its  congestion window by 4 packets (total 8 packets) if it is in slow-start, otherwise it will increase by 1 packet (total 5 packets). 

This means until increase in queueing delay is seen LEDBAT can be more aggressive than best-effort TCP. In the worst case, it can increase its congestion window so much that it will cause a loss on the best-effort TCP flow.

Thanks for thinking about it,
Padma

---

From: Stanislav Shalunov <[email-masked]>
Date: Tue, 13 Jul 2010 15:17:56 -0700

On Jul 13, 2010, at 7:24 AM, Padma Bhooma wrote:

> Let's say one best-effort TCP and one ledbat flow are sharing a  
> link. At some point in time they both have a congestion window of 4  
> packets each. Assume that LEDBAT measures a difference between  
> queuing delay estimate and the target delay of 10ms. This is the  
> off_target variable in the algorithm and includes the random_input.  
> In the next RTT, the LEDBAT flow will increase its congestion window  
> by 10 packets (total 14 packets). Whereas the best-effort TCP flow  
> will increase its  congestion window by 4 packets (total 8 packets)  
> if it is in slow-start, otherwise it will increase by 1 packet  
> (total 5 packets).

I've no idea where the 10 packets come from. Can you elaborate?

speed."

"GAIN SHOULD be set so that max rampup rate is the same as for TCP and  
MAY be up to twice more."

10 is clearly more than twice more than 1, so if an implementation is  
increasing by 10 packets per RTT, it is not following the spec.

This is about as direct as I can express this and seems to have worked  
for multiple independent implementors at this point.

If it is still confusing, see the BitTorrent uTP implementation, now  
open-source, and the use of the variable  
MAX_CWND_INCREASE_BYTES_PER_RTT.

Hope this helps,

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

> This means until increase in queueing delay is seen LEDBAT can be  
> more aggressive than best-effort TCP. In the worst case, it can  
> increase its congestion window so much that it will cause a loss on  
> the best-effort TCP flow.
>
>>> 2. The linear controller that LEDBAT uses suggests that the  
>>> congestion window should be increased proportional to the change  
>>> in one-way delay. This is very good for responding quickly to  
>>> changes in delay. But this can cause the window to increase at a  
>>> faster rate than TCP would do with its probing mechanism using  
>>> additive-increase. Although the maximum increase in window is  
>>> capped to be less than Best-effort TCP, the rate of increase can

---

From: Padma Bhooma <[email-masked]>
Date: Wed, 14 Jul 2010 09:21:19 -0700

> I've no idea where the 10 packets come from. Can you elaborate?

I just used a hypothetical off_target value and ignored GAIN which was a mistake. There is no implementation
that is/will be doing this.

> If it is still confusing, see the BitTorrent uTP implementation, now open-source, and the use of the variable MAX_CWND_INCREASE_BYTES_PER_RTT.
> 

Thanks for bringing up MAX_CWND_INCREASE_BYTES_PER_RTT. This is what I am looking for, a cap
on increase in congestion window per RTT. Although there is text alluding to this kind of a cap in the draft, I found the 
following link useful wrt explaining one possible way to calculate GAIN:

http://www.bittorrent.org/beps/bep_0029.html

Thanks,
Padma