Subject: Re: [ledbat] Review draft-ietf-ledbat-congestion-02 - part2

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 14 Sep 2010 15:14:32 +0200

Hi,

here is the more detailed review:

Abstract
========
Complete new proposal here:
"LEDBAT is an alternative experimental congestion control algorithm. LEDBAT 
enables a networking application to minimize the extra delay it induces in 
the bottleneck while saturating the bottleneck when no cross traffic is 
existent. LEBAT is based on one-way delay measurements and adjusts its 
sending rate depending on the difference of the actually delay with respect 
to a certain selected target delay. At the same time LEDBAT will be not more 
aggressive than today's TCP congestion control."

2. Introduction
------------------
-> reorder 3rd paragraph to:
"  LEDBAT is designed to allow to keep the latency across the congested
   bottleneck low even as it is saturated.  This allows applications
   that send large amounts of data, particularly upstream on home
   connections, such as peer-to-peer application, to operate without
   destroying the user experience in interactive applications.  LEDBAT
   takes advantage of delay measurements and backs off before loss
   occurs. This mechanism not only allows to keep delay across a
   bottleneck low, but also yields quickly in the presence of competing
   traffic with loss-based congestion control.

   LEDBAT has been deployed by BitTorrent in the wild first with
   the BitTorrent DNA client (a P2P-based CDN) and now with the uTorrent
   client. "

-> I would remove the last paragraph. I'm not sure if you can/would like to 
remove loss from the designed behavior and there are other ways to minimize 
delays as well.

3. LEDBAT design goals
-----------------
"1. saturate the bottleneck"
I don't think this should be the first design goal. And actually LEDBAT is not 
fulfilling this design goal as it only saturates the bottleneck if there is 
no other (TCP) connection active.

"  6.  be deployable for popular applications that currently comprise
       noticeable fractions of Internet traffic
   7.  where available, use explicit congestion notification (ECN),
       active queue management (AQM), and/or end-to-end differentiated
       services (DiffServ)."
Both points are not addressed in the remaining document. Either add these 
point somewhere or remove design goals (maybe shift to the Introduction".

I would suggest to add an additional point:
"  8. be no more aggressive than TCP congestion control" 

Would be nice to add to every point an short explanation what is meant and why 
the point is important.

4.  LEDBAT applicability
-----------------
"  ... and satisfies the wire format
   constraints (can carry timestamps, delay estimates, and has frequent
   ACKing).  Currently, no IETF standard transport specifies the use of
   LEDBAT, but all of TCP, DCCP, and SCTP could be adapted to use it."
Make those contraint that are import more explicit and explain why they are 
important.
- What should 'delay estimates' mean? Isn't the contraint to carry timestamps 
sufficient? 
- What does 'frequent ACKing' mean? How often has frequent to be to make 
LEDBAR working?

Please give a reference for the second paragraph or put results in the 
appendix. If those results can't be provided, I don't feel happy with having 
these statements here about test with high speeds.  

"On the low end of the link speed spectrum, LEDBAT works best with
   slower links when the packet size is reduced, thus reducing
   serialization delay.  On slower rural and wireless links, even a
   single 1500-byte packet can have a substantial serialization delay
   that, when combined with the protocol target delay, can become too
   large for VoIP applications sharing the bottleneck.  The mechanism to
   reduce packet size for slower networks is not further discussed in
   this document."
If you have such slow links, does VoIP work at all? And if you have such a 
slow link, should you reduce the LEDBAT TARGET then? I'm not sure if this 
paragraph is belonging in this document.

5.1.  Simplest network topology
--------------------
What's the statement of this paragraph? -> merge with 5.2.

5.3.  Queuing delay target
--------------------
"  ... scheduling delays in the OSes.  There's
   thus a good reason to try to make the queuing delay larger than this
   error.  There's no reason that would want us to push the delay much
   further up.  Thus, we will have a delay target that we would want to
   maintain."
What is the order of scheduling delay in the OSes? Do you have a reference? 
Does this number fit the proposed 25/100ms Target delay?

5.5.  Queing delay estimate
--------------------
"5.5.  Queing delay estimate" -> 5.5.  Queuing delay estimate

"  ... the constant propagation+serialization+processing
   delay is no less than the minimum delay observed."
That's not true. You might never observe the actually minimum delay without 
any queuing delays. 

5.8.  Halve on loss
-------------------
"  Note that, unlike with loss-based
   congestion control, the normal mode of LEDBAT operation does not
   induce losses and so normally does not rely on a loss rate to
   determine the sending rate."
What about Slow-Start and LEDBAT? As far as I understood by now LEDBAT needs 
to introduce loss at Slow-Start to kind of reset all LEDBAT flows and thus 
implement intra-protocol fairness...? I guess this whole discussion is 
missing in the draft.

5.11.  Measuring one-way delay
-------------------
This paragraph is more or less talking about the framing format where else 
5.16. is saying that this document doesn't specify the framing.

5.16.  LEDBAT framing and wire format
-------------------
"  ... as long as there is at
   least one ACK every round-trip time."
Is that sufficient? Would the feedback signal be quite noisy?

5.17.  Fairness between LEDBAT flows
--------------------
"  LEDBAT as described so far lacks a mechanism specifically designed to
   equalize utilization between these flows.  The observed behavior of
   existing implementations indicates that a rough equalization, in
   fact, does occur."
Please give a reference or add results to the appendix!

5.17.1.  Late comers
-------------------
"  However, once the initial flow yields, the late comer immediately
   measures the true base delay and the two flows operate from the same
   (correct) inputs."
Yes, the first flow backs off and the second will increase its sending rate 
until the first one is starved and the second one has the whole capacity... 
That doesn't work!?!

6.  LEDBAT congestion control
------------------
Please add reaction to loss to pseudo code.

Maybe give references where certain parts of the pseudo code are explain in 
the previous part of the document. Have a short paragraph to explain the 
different steps of the detailed pseudo code.

Please have a separate chapter to discuss the parametrization (see other 
email). 

Mirja

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 14 Sep 2010 15:30:29 +0200

Hi,

I just review the draft and I feel that the congestion control description was 
already in good shape with the first version but it hasn't much improve with 
this version. Some (important) points have been added but there are still 
several open questions.

I actually would like to propose to restructure the document as the current 
structure with 7 chapters and one off them having 18 subsections does not 
help me to get the overview whats missing...

Here is my proposal (open for discussion/changes):

   1.  Requirements notation  
   2.  Introduction 
     2.1.  LEDBAT design goals 
     2.2.  LEDBAT applicability (?)
     2.3.  LEDBAT requirements (put points about acking, need for ony-way 
delay aso. here?)
   3.  LEDBAT principles
     3.1.  Low extra delay (incl. 5.1. and 5.2.)  
        3.1.1  Queuing delay estimation (one-way) (incl. 5.4., 5.5. and 5.10.)  
        3.1.2  Base delay estimation (was: 5.12. Route changes)
        3.1.3  Queuing delay target 
     3.2. 'Window adaptation' or 'Sending speed adaptation' (was: 5.6. 
Controller) 
        3.2.1.  Max rampup rate same as TCP 
        3.2.2.  Reaction to loss 
	3.2.3.  Rate reduction (was: 5.9.  Yield to TCP) 
        3.2.4.  Windows size limitation for non-bulk flows (was: 5.15.)
     3.3.  Measuring one-way delay (incl.  and 5.11.) 
        3.3.1. LEDBAT framing and wire format
        3.3.2. Timestamp errors 
          3.3.2.1.  Clock offset  
          3.3.2.2.  Clock skew 
        3.3.3.  Noise filtering 
   4. ?? open issues/discussions ??
     4.2.  Fairness between LEDBAT flows  
     4.3.  Late comers 
     4.4.  Safety of LEDBAT
   5.  LEDBAT congestion control
     5.1.  Simplified mechanism
     5.2.  Detail Description
     5.3.  Parametrization
   6.  Security Considerations  

I'm gone send some more detailed comments in a next email but here some more 
general remarks:

1. There are several statements in the document that claims that LEDBAT 
behaves/works in a certain way in a certain situation because it has been 
tested by someone at sometime. I would like to see references for this to 
check the actual results of those studies otherwise you'd need to have a 
analytical/logical justification why thing are a certain way.

2. All the mechanisms used in 5.  LEDBAT congestion control should have 
already be motivated in 3.  LEDBAT principles. Maybe it's possible to give 
the right references at the right points here...

3. The abstract should hold a briefly description of the mechanism from my 
point of view. The Introduction should mostly give a motivation why LEDBAT is 
needed. Keep this separated from the design goals and usages scenario that 
should be described in the subsequent subsections.

4. There should be an extended discussion about the parametrization including 
lower and upper bounds if existing and a justification why a certain value 
has be chosen and what the consequences are to change them.

Mirja

On Thursday 19 August 2010 18:03:23 Rolf Winter wrote:
> Hi,
>
> here are some more comments on the draft:
>
> Please, I believe we do not endorse, rate or market products. Please remove
> "which is currently the most popular BitTorrent client".
>
> Add the mandatory IANA considerations section.
>
> "LEDBAT enables other advanced networking". You deleted "advanced" in the
> abstract, you might want to do that here too.
>
> Add reference for the One-Way Active Measurement Protocol
>
> s/To deal, base delay needs to be computed over a period of last few
> minutes instead of since the start of connection. The tradeoff is: for
> longer intervals, base is more accurate; for shorter intervals, reaction to
> route changes is faster./To deal with route change, the base delay needs to
> be computed over the last few minutes instead of since the start of
> connection. The tradeoff is: for longer intervals, the base delay is more
> accurate; for shorter intervals, the reaction to route change is faster.
>
> s/as Network Time Protocol (NTP)/as the Network Time Protocol (NTP)/
>
> "A 100-PPM skew means accumulating 6 milliseconds of error per minute.  The
> expiration of base delay related to route changes mostly takes care of
> clock skew." I am not sure this is a good suggestion. Given that we
> recommend a 10 minute base history (and up to 20 mins) the 6ms sum up to
> 60ms which is far above the delay target. Shouldn't we rather suggest to
> actually make use of a skew compensation scheme even if it is not specified
> in the document?
>
> I think the skew correction alternatives should go into an appendix if we
> want to keep them as they are not part of the spec but rather a reference.
> I am not sure we should include the Byzantine skew correction algorithm.
> That, I feel at least, seems the least cooked. Alternatively it could be
> better explained. I don't see e.g. why the median across all skews is a
> useful metric.
>
> "GAIN SHOULD be set so that max rampup rate is the same as for TCP and MAY
> be up to twice more." This is new and needs to be discussed. Is LEDBAT
> allowed to ramp up twice as fast as TCP?
>
> 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

-- 
-------------------------------------------------------------------
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: Wed, 15 Sep 2010 14:43:52 +0000

Stas/Greg, comments are piling up and I see no response from either of you. We really cannot converge at this rate. 

Thanks
Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind
Sent: Tuesday, September 14, 2010 6:15 AM
To: [email-masked]
Subject: Re: [ledbat] Review draft-ietf-ledbat-congestion-02 - part2

Hi,

Abstract
========
Complete new proposal here:
"LEDBAT is an alternative experimental congestion control algorithm. LEDBAT enables a networking application to minimize the extra delay it induces in the bottleneck while saturating the bottleneck when no cross traffic is existent. LEBAT is based on one-way delay measurements and adjusts its sending rate depending on the difference of the actually delay with respect to a certain selected target delay. At the same time LEDBAT will be not more aggressive than today's TCP congestion control."

2. Introduction
------------------

-> I would remove the last paragraph. I'm not sure if you can/would like 
-> to
remove loss from the designed behavior and there are other ways to minimize delays as well.

3. LEDBAT design goals
-----------------
"1. saturate the bottleneck"
I don't think this should be the first design goal. And actually LEDBAT is not fulfilling this design goal as it only saturates the bottleneck if there is no other (TCP) connection active.

Both points are not addressed in the remaining document. Either add these point somewhere or remove design goals (maybe shift to the Introduction".

Would be nice to add to every point an short explanation what is meant and why the point is important.

4.  LEDBAT applicability
-----------------
"  ... and satisfies the wire format
   constraints (can carry timestamps, delay estimates, and has frequent
   ACKing).  Currently, no IETF standard transport specifies the use of
   LEDBAT, but all of TCP, DCCP, and SCTP could be adapted to use it."
Make those contraint that are import more explicit and explain why they are important.
- What should 'delay estimates' mean? Isn't the contraint to carry timestamps sufficient? 
- What does 'frequent ACKing' mean? How often has frequent to be to make LEDBAR working?

Please give a reference for the second paragraph or put results in the appendix. If those results can't be provided, I don't feel happy with having these statements here about test with high speeds.  

If you have such slow links, does VoIP work at all? And if you have such a slow link, should you reduce the LEDBAT TARGET then? I'm not sure if this paragraph is belonging in this document.

"  ... the constant propagation+serialization+processing
   delay is no less than the minimum delay observed."
That's not true. You might never observe the actually minimum delay without any queuing delays. 

5.8.  Halve on loss
-------------------
What about Slow-Start and LEDBAT? As far as I understood by now LEDBAT needs to introduce loss at Slow-Start to kind of reset all LEDBAT flows and thus implement intra-protocol fairness...? I guess this whole discussion is missing in the draft.

5.11.  Measuring one-way delay
-------------------
This paragraph is more or less talking about the framing format where else 5.16. is saying that this document doesn't specify the framing.

5.17.1.  Late comers
-------------------
"  However, once the initial flow yields, the late comer immediately
   measures the true base delay and the two flows operate from the same
   (correct) inputs."
Yes, the first flow backs off and the second will increase its sending rate until the first one is starved and the second one has the whole capacity... 
That doesn't work!?!

Maybe give references where certain parts of the pseudo code are explain in the previous part of the document. Have a short paragraph to explain the different steps of the detailed pseudo code.

Please have a separate chapter to discuss the parametrization (see other email). 

Mirja

---

From: Sampo Syreeni <[email-masked]>
Date: Sat, 18 Sep 2010 01:25:36 +0300 (EEST)

On 2010-09-15, Murari Sridharan wrote:

Sorry to íntervene, but after reading all of the publicly available 
documents, I'm still left wondering about what the precise difference 
between µTP and the current state of LEDBAT is.

In particular it is weird that I haven't seen any perturbational 
experiment/analysis with all of the parameters of the protocol(s) at the 
same time, and especially against TCP. A bit of second order/sensitivity 
analysis would be nice as well, I think.

AFAICS, current LEDBAT and µTP do their job rather well. But still, it'd 
be nice to see a few pages worth of experimental data on LEDBAT before 
it goes into Standards Track. Personally I'm not that sure that it 
couldn't exceed its current bulk-transport efficiency and 
TCP-friendliness expectations, at the same time.

>"LEDBAT is designed to allow to keep the latency across the congested 
>bottleneck low even as it is saturated.  This allows applications that 
>send large amounts of data, particularly upstream on home connections, 
>such as peer-to-peer application, to operate without destroying the 
>user experience in interactive applications.  LEDBAT takes advantage of 
>delay measurements and backs off before loss occurs. This mechanism not 
>only allows to keep delay across a bottleneck low, but also yields 
>quickly in the presence of competing traffic with loss-based congestion 
>control. ["]

Personally, I'd shortly highlight the mechanism as well, and sell the 
mechanism. E.g. as in:

"LEDBAT is designed to keep the latency across any congested network 
path low even when saturated. It does so by sensing the one-way delay 
across a path and keeping it minimal, so that any buffer memory along 
the way is held as close to empty as possible. At the same time, LEDBAT 
tries to send as much data as possible: it tries to fill the most 
constrained buffer to the minimum extent in order to get the maximum 
continuous transfer rate. It has been shown that LEDBAT leads to higher 
bulk transfer rates than TCP, while at the same time causing less delay 
to interactive TCP traffic, such as HTTP, TELNET or SCP connections.

LEDBAT also helps limit downstream congestion, so that even bulk file 
sharing traffic no longer hurts the overall latency or fairness of most 
network flows. Unlike multiple simultaneous TCP flows, a number of 
LEDBAT connections will throttle back to an individual user's fair 
shair of the network capability."

> Please add reaction to loss to pseudo code.

That must be gotten verbatim from TCP Vegas or something newer. 
Preferably via reference, unless we plan to do something stricter. I 
mean, we're hanging off TCP because we can *never* be more aggressive 
than that. Thus it makes sense to somehow offload the specification to 
whoever does TCP, here.
-- 
Sampo Syreeni, aka decoy - [email-masked], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

---

From: Rolf Winter <[email-masked]>
Date: Mon, 20 Sep 2010 01:15:01 +0000

Sampo,

thanks for the comments. Just FYI, LEDBAT is not intended to go standards track but experimental. The WG is not chartered to do any document on standards track.

Best,

	Rolf

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sampo Syreeni
> Sent: Samstag, 18. September 2010 00:26
> To: Murari Sridharan
> Cc: [email-masked]
> experiment/analysis with all of the parameters of the protocol(s) at
> the same time, and especially against TCP. A bit of second
> order/sensitivity analysis would be nice as well, I think.
> 
> AFAICS, current LEDBAT and µTP do their job rather well. But still,
> it'd be nice to see a few pages worth of experimental data on LEDBAT
> before it goes into Standards Track. Personally I'm not that sure that
> it couldn't exceed its current bulk-transport efficiency and TCP-
> friendliness expectations, at the same time.
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 22 Sep 2010 14:29:51 +0200

Hi,

there are some Papers investigating LEDBAT from TELECOM ParisTech (Dario Rossi 
[1]) and NEC [2].

Still, the authors of the LEDBAT spec are referencing to tests made with the 
BitTorrent clients which are supposed to confirm things that hasn't been 
shown in the other papers incl. the discussion about the TARGET value and a 
MUST or SHOULD here. 

About this TARGET value topic: I not sure if we can converge to an proper 
solution here. But we should include the whole discussion in the document.

Mirja

[1] 
http://biblio.telecom-paristech.fr/cgi-bin/result.cgi?tmpl=public&searchtype=1&authortosearch=rossi&wordtosearch=LEDBAT&searchin=title&searchin=bibkey&year=&order=date&page=1&html=Display+the+selection

[2] Out of my Way -- Evaluating Low Extra Delay Background Transport in an 
ADSL Access Network. J. Schneider, J. Wagner, R. Winter, H. Kolbe 

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

---

From: Rolf Winter <[email-masked]>
Date: Wed, 22 Sep 2010 15:11:21 +0000

Hi,

I've been mulling about the parameterization of the target delay and the most recent change that has not received a lot of feedback (surprisingly). I am personally not confident to recommend it even experimentally without any reasoning why (other than BitTorrent has tested it with good results). So I suggest something to see what the WG thinks:

According to BCP 9 ""The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work,...". So I am suggesting to change the wording in the draft a little to make it clear that this is a record of the BitTorrent implementation rather than a recommendation from the IETF.

What do people think?

Best,

	Rolf

> Behalf Of Mirja Kuehlewind
> Sent: Mittwoch, 22. September 2010 14:30
> To: [email-masked]
> http://biblio.telecom-paristech.fr/cgi-
> bin/result.cgi?tmpl=public&searchtype=1&authortosearch=rossi&wordtosear
> ch=LEDBAT&searchin=title&searchin=bibkey&year=&order=date&page=1&html=D
> isplay+the+selection
> 
> the
> it'd
> that

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 25 Sep 2010 17:28:45 +0200

Dear all,

hoping that this can contribute to the draft discussion, I share on the 
list an overview of research work that focuses on the evaluation of 
LEDBAT performance, structured as:

* Available implementations
* Experimental studies
* Latecomer unfairness
* Sensitivity analysis and comparison
* References

this is just ment to be a short recap on the knowledge gained in the 
research community so far (so more a starting point than the final 
destination).

if you are aware of any further study I may have missed, please share it 
on the list

Best regards,
D.

--

* Available implementations

Recently, several implementations of LEDBAT appeared: to the best of our 
knowledge, only BitTorrent [BT] and the ns2+Linux [OPENLEDBAT] 
implementations are publicy available, while other implementations are 
used in performance evaluation studies such as [ITC22] and [ATQR] but 
not available online.

[BT] used to differ from LEDBAT specification in (1) the choice of a 
TARGET=100ms parameter (while in the draft is/was set to 25ms) and (2) 
in the use of variable framing (outside of draft scope).

So far, these implementation have not been experimentally compared.

* Experimental studies

The BitTorrent implementation (though based on the previous 
closed-source uTP and not on the open-source [BT] release) has been 
evaluated in [PAM], which points out that the level of low priority of 
LEDBAT depends on the TCP flavor and settings, and that cross traffic in 
the reverse path may have an important impact in practice.

Further details concerning the [BT] implementations are available in 
[IPTPS] where  BitTorrent details an algorithm to solve the problem of 
the clock drift in LEDBAT, that ameliorate the queuing delay estimation 
at the sender side.

The experimental work in [ITC22] exploits instead a own implementation 
and points that LEDBAT may not work as expected (and actually might be 
needed) in case active queue management techniques AQM are applied in 
user modems (the study also suggests AQM to become a default practice in 
set-top-box devices)

* Latecomer unfairness

In the simplest setup [ICCCN] points out the existence of a latecomer 
unfairness problem, that is also discussed in the mailing list.

[GLOBECOM] shows this to be tied to both the protocol dynamics as well 
as measurement errors, proposing simple solution.

[ICCCN,GLOBECOM] however assume FIFO queuing, and it would be 
interesting to see the impact of actually deployed AQM techniques as 
suggested in [ITC22].

[ARXIV] also shows the problem to be exacerbated by backlogged 
transmissions, in the sense that in chunk-by-chunk transmission, the 
time elapsed between consecutive chunks may flush the queue empty (and 
let latecomer correct their base delay estimate).

Interestingly, while [ITC22] observe a latecomer issue, this phenomenon 
is not observed in [ATQR].  [ARXIV] further shows that latecomer 
unfairness also arise on [BT] implementation (depending on the scenario).

* Sensitivity analisis and comparison

[ICCNT] propose a dynamic adjustation of LEDBAT parameters to address 
oscillations of congestion window in  steady state.

[LCN] performs a sensitivity analysis of LEDBAT (to the TARGET and GAIN 
settings) and also relatively compare the level of low-priority of 
LEDBAT, TCP-LP and TCP-NICE, showing LEDBAT to achieve the lowest priority.

A sensitivity to heterogeneous TARGETs settings (i.e., the fact that 
Legacy implementations with higher TARGETs may starve compliant 
implementation) has been pointed out in the mailing list and [ITC22,LCN].

Hence, chosing a single, fixed TARGET value remains an open point.

* References

[BT]
G. Hazel. uTorrent Transport Protocol library. 
http://github.com/bittorrent/libutp, May 2010.

[OPENLEDBAT] http://perso.infres.enst.fr/~drossi/index.php?n=Software.LEDBAT

[ITC22]
Joscha Schneider. Joerg Wagner,  Rolf Winter ,  Hans-Joerg Kolbe,
"Out of my Way -- Evaluating Low Extra Delay Background Transport in an 
ADSL Access Network" . In Proceedings of the 22nd International 
Teletraffic Congress (ITC22), Amsterdam, The Netherlands, September 7 - 
9 2010.

[AQTR]
Mugurel Ionut Andreica, Nicolae Tapus, Johan Pouwelse, "Performance 
Evaluation of a Python Implementation of the New LEDBAT Congestion 
Control Algorithm", Proceedings of the IEEE International Conference on 
Automation, Quality and Testing, Robotics (AQTR'10), Romania, 28-30 May, 
2010
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5520827

[IPTPS]
B. Cohen and A. Norberg. "Correcting for clock drift in uTP and
LEDBAT." Invited talk at 9th USENIX International Workshop on
Peer-to-Peer Systems (IPTPS 2010), San Jose, CA, Apr 2010.
http://www.usenix.org/event/iptps10/tech/slides/cohen.pdf

[ICCNT]
A.J. Abu and S. Gordon. "A Dynamic Algorithm for Stabilising
LEDBAT Congestion Window." In 2nd IEEE International Conference on
Computer and Network Technology (ICCNT 2010), Bangkok, Thailand,
Apr 2010.
http://www.computer.org/portal/web/csdl/doi/10.1109/ICCNT.2010.37

[PAM]
D. Rossi, C. Testa and S. Valenti, "Yes, we LEDBAT: Playing with the new 
BitTorrent congestion control algorithm" . In Passive and Active 
Measurement (PAM'10), Zurich, Switzerland, April 2010.
http://www.pam2010.ethz.ch/papers/full-length/4.pdf

[ICCCN]
D. Rossi, C. Testa, S. Valenti and L. Muscariello, "LEDBAT: the new 
BitTorrent congestion control protocol" . In International Conference on 
Computer Communication Networks (ICCCN'10), Zurich, Switzerland, August 
2-5 2010.
http://ieeexplore.ieee.org/iel5/5559661/5560011/05560080.pdf

[LCN]
G. Carofiglio, L. Muscariello, D. Rossi and C. Testa, "A hands-on 
Assessment of Transport Protocols with Lower than Best Effort Priority" 
. In 35th IEEE Conference on Local Computer Networks (LCN'10), Denver, 
CO, USA, October 10-14 2010.
http://arxiv.org/pdf/1006.3017

[GLOBECOM]
G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, "The quest for 
LEDBAT fairness". In IEEE Globecom'10, Miami, FL, USA, December 6-10 2010.
http://arxiv.org/pdf/1006.3018v1

[ARXIV] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti,
"Rethinking low extra delay background transport protocols"
arXiv.org

-- 
         Dario Rossi
   Oo    Associate Professor
    >     TELECOM ParisTech
   ~     (formerly ENST)

mail:  [email-masked]
phone: +33.1.4581.7563
fax:   +33.1.4581.7158
web:   http://www.enst.fr/~drossi

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 29 Sep 2010 14:09:32 +0200

Hi Rolf,

sorry for the late response. I temped to rely immediately but then I figured 
out I'm not sure what to answer. I' m still not sure but here are my 
thoughts:

I would appreciate to document am Low Extra Delay Background Transport which 
can be used for various applications rather than having a wholing working 
group for documenting one specific solution of one specific company.
On the other hand having a record of the Bittorrent algorithm might also 
provide a guideline how to implement LEDBAT with other applications. But no 
matter if we decide for the one or the other way there are still several open 
issues which should be addressed in every record. E.g. regarding the TARGET 
value I would at least except a small discussion in the document why a 
specific value was chosen. 

I would like to finish this w-g as soon as possible as well. There doesn't 
seem to be too much intrest any more. But I don't see how this can be done 
without the input of the authors of the main protocol spec..?

Mirja

On Wednesday 22 September 2010 17:11:21 Rolf Winter wrote:
> Hi,
>
> I've been mulling about the parameterization of the target delay and the
> most recent change that has not received a lot of feedback (surprisingly).
> I am personally not confident to recommend it even experimentally without
> any reasoning why (other than BitTorrent has tested it with good results).
> So I suggest something to see what the WG thinks:
>
> According to BCP 9 ""The "Experimental" designation typically denotes a
> specification that is part of some research or development effort. Such a
> specification is published for the general information of the Internet
> technical community and as an archival record of the work,...". So I am
> suggesting to change the wording in the draft a little to make it clear
> that this is a record of the BitTorrent implementation rather than a
> recommendation from the IETF.
>
> What do people think?
>
> Best,
>
> 	Rolf
>
>
> > > same time, and especially against TCP. A bit of second
> >
> > order/sensitivity
> >
> > > be nice to see a few pages worth of experimental data on LEDBAT
> >
> > before
> >
> > > >"LEDBAT is designed to allow to keep the latency across the
> >
> > congested
> >
> > > >send large amounts of data, particularly upstream on home
> >
> > connections,
> >
> > > >user experience in interactive applications.  LEDBAT takes advantage
> >
> > of
> >
> > > >delay measurements and backs off before loss occurs. This mechanism
> >
> > not
> >
> > > >quickly in the presence of competing traffic with loss-based
> >
> > congestion
> >
> > > >control. ["]
> > >
> > > the way is held as close to empty as possible. At the same time,
> >
> > LEDBAT
> >
> > > continuous transfer rate. It has been shown that LEDBAT leads to
> >
> > higher
> >
> > > bulk transfer rates than TCP, while at the same time causing less
> >
> > delay
> >
> > > sharing traffic no longer hurts the overall latency or fairness of
> >
> > most
> >
> > > than that. Thus it makes sense to somehow offload the specification
> >
> > to
> >
> > > whoever does TCP, here.
> >
> > --

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

---

From: Rolf Winter <[email-masked]>
Date: Thu, 30 Sep 2010 01:53:42 +0000

Hi Mirja,

Thanks for your input. See inline:

> provide a guideline how to implement LEDBAT with other applications.

Just because this is a document recording a specific implementation does not imply it cannot or should not be implemented more widely (except if there are IPR issues which we have not seen evidence for). No matter what we do, there is requirements language in the document which is the guideline you are looking for. 

> But no

I agree. Preferably the authors should come forward with an explanation but also the WG should discuss this, unfortunately neither has happened.

> without the input of the authors of the main protocol spec..?

With the help of the WG. But again, this requires the WG to actually start discussing this issue.

Best,

	Rolf