Subject: [ledbat] Fwd: New Version Notification for draft-ietf-ledbat-congestion-08.txt

From: Janardhan Iyengar <[email-masked]>
Date: Sun, 09 Oct 2011 16:51:43 -0700

Dear all,

A new version of the congestion control draft is in the repository. There are two major mods in this revision:

1/ WGLC identified one major issue that needed to be addressed in the LEDBAT congestion control draft -- LEDBAT response to extreme congestion -- and we've tried to address that issue in this revision. We've added a new mechanism, the Congestion Timeout (CTO), for a sender to respond to extreme congestion. We do not specify how this should be implemented, but we do note that a CTO can be implemented with or without a timer. In terms of textual changes, we've added an update_CTO() function and a branch for what to do if no acks are received within a CTO amount of time in Section 3.4.2. We have changed the response to data loss to ensure that a protocol, such as TCP, that uses the same timer for both congestion control and for retransmissions, changes its cwnd correctly.

2/ We have set the values for INIT_CWND to 4 and MIN_CWND to 2, and have clarified the discussion of CURRENT_DELAYS and INIT_CWND/MIN_CWND in Section 3.5.

Please comment!
- jana

-- 
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar

-------- Original Message --------
Subject: New Version Notification for draft-ietf-ledbat-congestion-08.txt
Date: Sun, 09 Oct 2011 16:33:33 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked],	[email-masked], [email-masked]

A new version of I-D, draft-ietf-ledbat-congestion-08.txt has been successfully submitted by Janardhan Iyengar and posted to the IETF repository.

Filename:	 draft-ietf-ledbat-congestion
Revision:	 08
Title:		 Low Extra Delay Background Transport (LEDBAT)
Creation date:	 2011-10-09
WG ID:		 ledbat
Number of pages: 19

Abstract:
    LEDBAT is an experimental delay-based congestion control algorithm
    that attempts to utilize the available bandwidth on an end-to-end
    path while limiting the consequent increase in queueing delay on the
    path.  LEDBAT uses changes in one-way delay measurements to limit
    congestion that the flow itself induces in the network.  LEDBAT is
    designed for use by background bulk-transfer applications; it is
    designed to be no more aggressive than TCP congestion control and to
    yield in the presence of any competing flows when latency builds,
    thus limiting interference with the network performance of the
    competing flows.

The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Oct 2011 07:37:31 -0700

On 10/9/2011 4:51 PM, Janardhan Iyengar wrote:
> Dear all,
>
> A new version of the congestion control draft is in the repository.
> There are two major mods in this revision:
...
> 2/ We have set the values for INIT_CWND to 4 and MIN_CWND to 2, and have
> clarified the discussion of CURRENT_DELAYS and INIT_CWND/MIN_CWND in
> Section 3.5.

It might be more stable to refer to TCP's INIT_CWND and MIN_CWND values, 
i.e., that ledbat should use TCP's values for these.

(they've been under discussion for revision in TCPM, FWIW)

Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 10 Oct 2011 18:46:26 +0200

Hi,

I wouldn't want to refer to TCP's value because of a less-than-best-effort 
traffic there might always be a motivation to take different/lower values 
than TCP.

Mirja

On Monday 10 October 2011 16:37:31 Joe Touch wrote:
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

-- 
-------------------------------------------------------------------
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: Joe Touch <[email-masked]>
Date: Mon, 10 Oct 2011 10:46:31 -0700

> traffic there might always be a motivation to take different/lower values

The values currently suggested are TCP's current values. I don't mind if 
you want to pick smaller ones, but I'd suggest spec'ing them relative to 
TCP's current values regardless.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 15 Oct 2011 08:41:11 +0100

The latest text for the LEDBAT draft says:

    INIT_CWND SHOULD be 4, and MIN_CWND SHOULD be 2.  An INIT_CWND of 4
    should help seed FILTER() at the sender when there are no samples at
    the beginning of a flow, and a MIN_CWND of 2 allows FILTER() to use
    more than a single instantaneous delay estimate while not being too
    aggressive.  Slight deviations may be warranted, for example, when
    these values of MIN_CWND and INIT_CWND interact poorly with the
    framing protocol.

I commented previously on this, and here are my thoughts on the new text.

I would personally be OK with starting with a window of 4.

I do not agree that an update to TCP should be tracked by LEDBAT in the 
general case, because as I understand, the value 4 is derived from the 
operation of LEDBAT itself - i.e. use of the filter.

  In general, I like the idea of explaining when the SHOULD may be 
violated and what the implications are. However, the present clause at 
the end of this para seems to suggest ANY other value could also be OK, 
I do not agree this is to be left to the implementer - I was hoping here 
to see this limited to a fraction of the current TCP initial window, 
e.g. "but SHOULD NOT be larger than Max (4, one half of the initial 
window specified for TCP, currently [RFC3390])." However, I suspect that 
starting small is a very good idea for a longer-lived background flow 
that intends to be less aggressive than other flows, and should have 
little impact on the overall download time, therefore it may be better 
to just leave the recommendation as should use 4 in the first RTT.

Gorry
On 10/10/2011 18:46, Joe Touch wrote:
> The values currently suggested are TCP's current values. I don't mind 
> if you want to pick smaller ones, but I'd suggest spec'ing them 
> relative to TCP's current values regardless.
>
> Joe
>
>>
>> Mirja
>>
>>

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Sat, 15 Oct 2011 09:37:06 +0100

Dear Jana and others,

 I went through the draft and am currently trying to figure out what
the performance implications are with the latest draft through
simulations (I have a few helpful UG students in India who have
volunteered to do this for me - this includes modifying the current
ns-2 code to reflect the latest draft). But unfortunately, I dont
think we will be able to tell anything useful before WGLC ends!

However I have one question ->
 " A CTO is used to detect heavy congestion indicated by loss of all
  outstanding data or acknowledgments, resulting in reduction of the
  cwnd to 1 MSS and an exponential backoff of the CTO interval"

So I am trying to see  whether heavy congestion actually means loss of
"ALL" outstanding segments - so how does LEDBAT behave according to
the current draft if atleast one packet went through? Just trying to
understand.

Regards
Arjuna

On 10 October 2011 00:51, Janardhan Iyengar <[email-masked]> wrote:
> 1/ WGLC identified one major issue that needed to be addressed in the LEDBAT
> congestion control draft -- LEDBAT response to extreme congestion -- and
> we've tried to address that issue in this revision. We've added a new
> mechanism, the Congestion Timeout (CTO), for a sender to respond to extreme
> congestion. We do not specify how this should be implemented, but we do note
> that a CTO can be implemented with or without a timer. In terms of textual
> changes, we've added an update_CTO() function and a branch for what to do if
> no acks are received within a CTO amount of time in Section 3.4.2. We have
> changed the response to data loss to ensure that a protocol, such as TCP,
> that uses the same timer for both congestion control and for
> retransmissions, changes its cwnd correctly.
>
> clarified the discussion of CURRENT_DELAYS and INIT_CWND/MIN_CWND in Section
> 3.5.
>
> Please comment!
> - jana
>
> --
> Janardhan Iyengar
> CC: [email-masked], [email-masked],
>  [email-masked], [email-masked]
>
> A new version of I-D, draft-ietf-ledbat-congestion-08.txt has been
> successfully submitted by Janardhan Iyengar and posted to the IETF
> repository.
>

--
http://about.me/arjuna.sathiaseelan

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Sat, 15 Oct 2011 09:56:49 +0100

Another thing which I forgot to point out - in section 3.4.1 the term
off_target suddenly pops up without an explanation. That needs to be
resolved please.

Regards
Arjuna

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Oct 2011 07:09:08 -0700

Hi, Gorry (et al.),

On Oct 15, 2011, at 12:41 AM, Gorry Fairhurst wrote:

> I do not agree that an update to TCP should be tracked by LEDBAT in the general case, because as I understand, the value 4 is derived from the operation of LEDBAT itself - i.e. use of the filter.

Sec 3.2:

   In addition to the LEDBAT mechanism described below, we note that a
   slow start mechanism can be used as specified in [RFC5681].  Since
   slow start leads to faster increase in the window than that specified
   in LEDBAT, conservative congestion control implementations employing
   LEDBAT may skip slow start altogether and start with an initial
   window of INIT_CWND * MSS.  (INIT_CWND is described later in
   Section 3.5.)

Sec 3.5:
   A LEDBAT sender uses the current_delays list to maintain only delay
   measurements made within a RTT amount of time in the past, seeking to
   eliminate noise spikes in its measurement of the current one-way
   delay through the network.  The size of this list, CURRENT_FILTER,
   may be variable, and depends on the number of successful measurements
   made within a RTT amount of time in the past.  The sender should seek
   to gather enough delay samples in each RTT so as to have statistical
   confidence in the measurements.  While the number of delay samples
   required for such confidence will vary depending on network
   conditions, we recommend that the sender SHOULD use at least 4
   samples in each RTT, unless the number of samples is lower due to a
   small congestion window.  Thus, subject to congestion window
   constraints, the number of delay samples in each RTT SHOULD be at
   least 4, and thus CURRENT_FILTER SHOULD be at least 4.
   CURRENT_FILTER MUST be limited such that samples in the list are not
   older than an RTT in the past.

For INIT_CWND, the number 4 is derived from a notion of the minimum number of samples needed to make FILTER work. However, it clearly should not be larger than TCP's INIT_CWND, and the number 4 appears to be related to a misunderstanding of TCP's initial value (see below), not picked solely for its ability to generate meaningful statistics.

IMO, the right description would be:

	no smaller than needed to ensure a reasonable number of samples
	no larger than TCP's current values

Note that the definition of "reasonable number of samples" can be described more clearly as, e.g.,

	SHOULD use enough saamples to yield a variance of less than 25% 

I'm not sure whether "variance" or some other confidence interval should be specified, or whether 25% is better than other values. However, the current text is vague on both points.

> In general, I like the idea of explaining when the SHOULD may be violated and what the implications are. However, the present clause at the end of this para seems to suggest ANY other value could also be OK, I do not agree this is to be left to the implementer - I was hoping here to see this limited to a fraction of the current TCP initial window, e.g. "but SHOULD NOT be larger than Max (4, one half of the initial window specified for TCP, currently [RFC3390])." However, I suspect that starting small is a very good idea for a longer-lived background flow that intends to be less aggressive than other flows, and should have little impact on the overall download time, therefore it may be better to just leave the recommendation as should use 4 in the first RTT.
> 
> Gorry

Unfortunately, the equation above yields a current value of 1 (RFC3990 is 4 MSS *or* 4KB, whichever is smaller, and for 1500-byte MTUs that is 3; half of 3 would round down to 1).

Even picking TCP's current INIT_CWND should be 3, not 4, based on typical MSS sizes.

So this analysis indicates a big problem with INIT_CWND in LEDBAT - the smallest viable value needs to be large enough to have a meaningful average, but lower than TCP's INIT_CWND, and there doesn't appear to be a currently viable value.

Further, INIT_CWND should always be divisible by the ACK frequency (e.g., if 1 ACK per 2 MSS, then divisible by 2), to avoid unnecessary delays due to the ACK frequency compression.

MIN_CWND IMO should be defined as half INIT_CWND, *NOT* as a fixed value in this doc.

Joe

>> The values currently suggested are TCP's current values. I don't mind if you want to pick smaller ones, but I'd suggest spec'ing them relative to TCP's current values regardless.
>> 
>> Joe
>> 
>>> 
>>> Mirja
>>> 
>>>

---

From: David Ros <[email-masked]>
Date: Tue, 18 Oct 2011 17:29:49 +0200

Le 17 oct. 2011 à 16:09, Joe Touch a écrit :

> [...]

Hi all,

Sorry if I'm getting this totally wrong, but: is it really *necessary* that LEDBAT's INIT_CWND be *smaller* than TCP's? As far as I understand, the point of LEDBAT is to be less-than-best-effort over (relatively) long timescales, or at least over time scales longer than one (initial) RTT. And just starting up as TCP won't make it *more* aggressive than TCP. Is this correct??

(of course, this doesn't change anything to other points made by Joe -- e.g., if LEDBAT uses INIT_CWND = 4 then it'll start by sending more than what TCP would -- i.e., 3 segments -- with typical MSS values)

Thanks,

David.

>>>>> (they've been under discussion for revision in TCPM, FWIW)

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

In theory, theory and practice are the same. In practice, they are different. -- Author unknown

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Oct 2011 12:27:02 -0700

On 10/18/2011 8:29 AM, David Ros wrote:
...
> Hi all,
>
> Sorry if I'm getting this totally wrong, but: is it really
> *necessary*
> that LEDBAT's INIT_CWND be *smaller* than TCP's? As far as I understand,
> the point of LEDBAT is to be less-than-best-effort over (relatively)
> long timescales, or at least over time scales longer than one (initial)
> RTT. And just starting up as TCP won't make it *more* aggressive than
> TCP. Is this correct??

No, but it could make it a lot like TCP if the offered load is in short 
bursts. If that's not the intent, then the INIT_CWND needs to be smaller 
than TCP's.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 19 Oct 2011 08:26:24 +0100

> bursts. If that's not the intent, then the INIT_CWND needs to be smaller

I think INIT_CWND should not be significantly bigger than *deployed* TCP 
INIT_CWND. (It may of course be desirable to be smaller or the same, and 
that would benefit in the way Joe suggested).

When I suggested "4" could be OK, this was only 1 larger than current 
usage for a 1500B MTU, and equivalent for some smaller MTU. That to me 
is not "significantly bigger". It would seem OK, because if this induced 
congestion LEDBAT would react within INIT_CWND segments in a 
conservative way.

If we care about LEDBAT being conservative compared to other TCP 
sessions, then I really think we should not track future new proposals 
to raise INIT_CWND. I suggest this would have side effects:

- It could make LEDBAT more aggressive than *deployed* TCP 
implementations, that I think would be bad.

- It may require LEDBAT to implement additional algorithms to ensure it 
is conservative when the larger INIT_CWND induces congestion. Addressing 
this would likely add complexity to LEDBAT and make it dependent on 
these TCP updates (if any).

I think a larger INIT_CWND (e.g. by tracking any evolution of TCP's 
INIT_CWND) is unwarranted if the goal is for LEDBAT to target  bulk 
less-than-best-effort use. I cannot see the case yet for a LEDBAT 
INIT-CWND beyond 4. Raising this could indeed save an RTT at the start 
of a LEDBAT flow, but this would be at the expense of making it 
(slightly) more aggressive than presently deployed TCP. This seems 
undesirable.

I also suggested that MIN_CWND should similarly be fixed to a small number.

Gorry

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Wed, 19 Oct 2011 09:34:59 +0100

I agree to these points too that LEDBAT MUST NOT evolve its initial
 window to a larger value.

 To solve the issue of bursts as Joe pointed out, do we need LEDBAT to
 be rate paced (atleast during the initial phases)?

 Arjuna

> On 19 October 2011 08:26, Gorry Fairhurst <[email-masked]> wrote:
>> When I suggested "4" could be OK, this was only 1 larger than current usage
>> for a 1500B MTU, and equivalent for some smaller MTU. That to me is not
>> "significantly bigger". It would seem OK, because if this induced congestion
>> LEDBAT would react within INIT_CWND segments in a conservative way.
>>
>> If we care about LEDBAT being conservative compared to other TCP sessions,
>> then I really think we should not track future new proposals to raise
>> INIT_CWND. I suggest this would have side effects:
>>
>> - It could make LEDBAT more aggressive than *deployed* TCP implementations,
>> that I think would be bad.
>>
>> - It may require LEDBAT to implement additional algorithms to ensure it is
>> conservative when the larger INIT_CWND induces congestion. Addressing this
>> would likely add complexity to LEDBAT and make it dependent on these TCP
>> updates (if any).
>>
>> less-than-best-effort use. I cannot see the case yet for a LEDBAT INIT-CWND
>> beyond 4. Raising this could indeed save an RTT at the start of a LEDBAT
>> flow, but this would be at the expense of making it (slightly) more
>> aggressive than presently deployed TCP. This seems undesirable.
>>

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Oct 2011 10:14:53 -0700

Hi, Gorry,

I agree with your logic, but it suggests INIT_CWND and MIN_CWND should 
be 2 - those are both clearly safe, clearly smaller than the current 
deployed base, and would not increase to track TCP's increases.

Joe

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 28 Oct 2011 15:37:33 +0200

Hi Arjuna,

heavy congestion does mean that for CTO time no data have been received. If 
data was received LEDBAT will compare the respective delay measurement with 
the base delay and increase or decrease the cwnd (except it is already 
MIN_CWND). Then if less packets are in flight than the cwnd allows it will 
send out a packet. Normally, if in CTO time no packet was received, it is 
assumed that all packets are loss and fightsize might be reset to 0. But an 
algorithm how to detect packet loss is independent from LEDBAT and thus not 
described in this draft.

I hope that helps...?

Thanks for your feedback!
Mirja

On Saturday 15 October 2011 10:37:06 Arjuna Sathiaseelan wrote:
> > 1/ WGLC identified one major issue that needed to be addressed in the
> > LEDBAT congestion control draft -- LEDBAT response to extreme congestion
> > -- and we've tried to address that issue in this revision. We've added a
> > new mechanism, the Congestion Timeout (CTO), for a sender to respond to
> > extreme congestion. We do not specify how this should be implemented, but
> > we do note that a CTO can be implemented with or without a timer. In
> > terms of textual changes, we've added an update_CTO() function and a
> > branch for what to do if no acks are received within a CTO amount of time
> > in Section 3.4.2. We have changed the response to data loss to ensure
> > that a protocol, such as TCP, that uses the same timer for both
> > congestion control and for

tel: +49(0)711/685-67973

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 28 Oct 2011 15:52:50 +0200

Thanks, Arjuna.

I added two sentences here:
"LEDBAT takes the minimum delay it measures at any time as the base delay and 
compares the current delay measurement to this value to calculate the queuing 
delay. off_target compares the queuing delay to the dedicated TARGET chosen 
and is normalizes by the TARGET value itself."

Does this work?

Mirja

On Saturday 15 October 2011 10:56:49 Arjuna Sathiaseelan wrote:
> >> extreme congestion. We do not specify how this should be implemented,
> >> but we do note that a CTO can be implemented with or without a timer. In
> >> branch for what to do if no acks are received within a CTO amount of
> >> time in Section 3.4.2. We have changed the response to data loss to
> >> ensure that a protocol, such as TCP, that uses the same timer for both
> >> Subject: New Version Notification for
> >> draft-ietf-ledbat-congestion-08.txt Date: Sun, 09 Oct 2011 16:33:33
> >> -0700

tel: +49(0)711/685-67973

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Fri, 28 Oct 2011 17:10:30 +0100

Hello Mirja,
  How about this?

"LEDBAT takes the minimum delay it measures at any time as the base delay and
compares the current delay measurement to this value to calculate the queuing
delay. off_target compares the queuing delay to the chosen TARGET delay
and normalizes itself to the TARGET value."

Regards
Arjuna

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Fri, 28 Oct 2011 17:12:42 +0100

Thanks Mirja - that helps :)..

Regards
Arjuna