Re: [ledbat] New Version Notification for draft-ietf-ledbat-congestion-07.txt

[Dario Rossi <[e-mail]>]

Hello all,

I have gone only through section 5.3. Fairness Among LEDBAT Flows:  I 
can say I *almost* entirely agree with 5.3 except that in real life 
fairness issue remains with *backlogged* flows, while the drafts mislead 
the reader into believing this is not the case

once again,  Fig1, pag2 in [ARXIV] has been gathered on a *real testbed 
with libUTP code* https://github.com/bittorrent/libutp  --  basically, 
that figure it confirms what we early saw via ns2 simulation in Fig3 
pag5 in [ICCCN].

I am not saying this is *the default settings for BitTorrent* where we 
expect may short flows due to chunk based transmission (called otherwise 
in the draft but I am perfectly fine with the draft wording) to lessen 
latecomer effect

at the same time, imo the IETF LEDBAT draft should be applicable to a 
larger extent, where *possibly LEDBAT is used for backlogged transfers* 
(eg. as simple as a couple of low priority background FTP transfers over 
LEDBAT): and in that settings, there is no way imo you can get rid of 
latecomer with aiad.

however,  I am not seeing any trace of this in the draft; rather, I see 
that 5.3 ends with:

         "With a small number of LEDBAT flows, system noise may 
sufficiently regulate the late-comer's advantage."

If I would be editing the document myself, I would rather write (sorry 
for being a pain in the neck, but I am technically conviced of that point):

         "With a small number of LEDBAT flows, system noise may 
sufficiently regulate the late-comer's advantage provided flows are non 
backlogged. In case of backlogged connections, latecomer advantage may 
still arise [ARXIV]."


imo, anybody taking the libUTP code and redoing the simple testbed 
experiment can convice himself latecomer truly holds: i.e., [ARIXV] is 
right and 5.3 is wrong (I think I cannot make the point more clear than 
that)

however, as I am not an author of the draft, I think that adoption of 
the above text is a matter of the discussion of the WG: thus, if the WG 
thinks that nowhere on earth we are ever gonna see backlogged 
connections again, then no harm will be done and 5.3 can stay as it is


regards,
D.



[ARXIV] G. Carofiglio, L. Muscariello, D. Rossi and S. Valenti, 
"Rethinking low extra delay background transport protocols" 
http://arxiv.org/abs/1010.5623

[ICCCN] D. Rossi, C. Testa, S. Valenti and L. Muscariello, *LEDBAT: the 
new BitTorrent congestion control protocol* 
<http://www.enst.fr/%7Edrossi/paper/rossi10icccn.pdf> . In 
/International Conference on Computer Communication Networks 
(ICCCN'10)/, Zurich, Switzerland, August 2-5 2010.



On 07/20/2011 10:23 AM, Rolf Winter wrote:
> Hello,
>
> could Dario, Bob, Gorry and Arjuna please check whether your comments are resolved. This would help us make progress.
>
> Thanks,
>
>
> Rolf
>
>
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
>
>
>> -----Original Message-----
>> From: Janardhan Iyengar [mailto:[e-mail]]
>> Sent: Donnerstag, 14. Juli 2011 18:46
>> To: [e-mail]; Mirja Kuehlewind; Murari Sridharan; Rolf Winter
>> Subject: Fwd: New Version Notification for draft-ietf-ledbat-
>> congestion-07.txt
>>
>> Hi all,
>>
>> We've posted a new version of the LEDBAT document that addresses all
>> issues brought up in WGLC but one.  Besides some nits, the main changes
>> are:
>> 1. We changed the text in the Fairness section to more accurately
>> reflect possible issues with LEDBAT's fairness. (Dario's comments)
>> 2. The applicability section now has better articulation about LEDBAT's
>> interactions with with ECN and AQM. (Bob's, Gorry's, Arjuna's comments)
>>
>> We haven't yet addressed the MIN_CWND issue under extreme congestion;
>> we hope to resolve this issue at the IETF.  We are planning to not
>> discuss the question of incentivizing ECN within this document.  It
>> seems like a question that is worth considering in a broader context
>> and needs more discussion;  at this late hour (in/after WGLC), it seems
>> like an issue that we may not be able to resolve here.  It can
>> certainly be brought to the table if/when LEDBAT goes from experimental
>> to standards-track.
>>
>> - jana
>>
>> -------- Original Message --------
>> Subject: New Version Notification for draft-ietf-ledbat-congestion-
>> 07.txt
>> Date: Mon, 11 Jul 2011 10:57:51 -0700
>> From: [e-mail]
>> To: [e-mail]
>> CC: [e-mail], [e-mail],
>> 	[e-mail], [e-mail]
>>
>> A new version of I-D, draft-ietf-ledbat-congestion-07.txt has been
>> successfully submitted by Mirja Kuehlewind and posted to the IETF
>> repository.
>>
>> Filename:	 draft-ietf-ledbat-congestion
>> Revision:	 07
>> Title:		 Low Extra Delay Background Transport (LEDBAT)
>> Creation date:	 2011-07-11
>> WG ID:		 ledbat
>> Number of pages: 18
>>
>> 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
> _______________________________________________
> ledbat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ledbat


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

mail:  [e-mail]
phone: [phone]
fax:   [phone]
web:   http://www.enst.fr/~drossi