Subject: Re: [ledbat] open issues, delay target MUST/SHOULD

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 8 Jul 2010 18:02:34 +0200

Hi again,

On Tuesday 08 June 2010 16:05:46 Rolf Winter wrote:
> 2. MUST/SHOULD/SHALL on the delay target
> Should the delay target be MUST or SHOULD (or something else). There was a
> discussion on whether the delay target should be required to be 25ms. Stas
> argued it is needed for interoperability. But some people argued it would
> be good if people were allowed to experiment with different values. I
> personally think this should be fixed. My argument would be that if people
> were allowed to fiddle with the 25 ms they will in order to have their app
> to perform better. Imagine two p2p applications running behind a common
> bottleneck (in your home network e.g.). The one choosing a slightly higher
> target will win over the other. We did experiments with this and found a
> few milliseconds to be sufficient. This potentially is an open invitation
> to an arms race amongst app developers I think. I'd like to hear more
> arguments for either one or the other.
This is a very good point but its just true if you have e.g. two p2p apps 
competing again each other. If two different kind of applications are sharing 
the same bottleneck they might have different requirements for their 
transport and it might be the right thing that one app is raising the other. 
Of cause then you need something/someone to 'control/observe' this but this 
goes somehow in-line with the ideas behind ConEx.

How I understood the delay target should say how many packets will be okay to 
be queue in the bottleneck router. But this value actually depends on the 
bottleneck bandwidth. I guess this question was already asked at a time, but 
I'll gone ask again. Is it possible to set the delay target dynamically 
depending on a max available bandwidth?
@Rolf: Do I remember right that you did some tests about this? Can you tell 
about?

And even if we say the delay target should be fixed (using MUST) the question 
what is the right value is still open. Maybe there must be specified several 
values for several usage scenario (p2p or somethingelse...)...?

Mirja

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 8 Jul 2010 21:01:56 -0400

> If two different kind of applications are sharing the same bottleneck they might have different requirements for their transport and it might be the right thing that one app is raising the other.

My question would be, if there are two applications using two different delay targets, does the application with the higher delay target starve the application with the lower delay target?

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
Sent: Thursday, July 08, 2010 12:03 PM
To: [email-masked]
Subject: Re: [ledbat] open issues, delay target MUST/SHOULD

Hi again,

Mirja  

_______________________________________________
ledbat mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ledbat

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 9 Jul 2010 10:40:40 +0200

Hi,

attached some results from measurements we did (several home gateways, MSAN, and SW BRAS setup). Forget the lower figure for now. But the middle one is the interesting one. In this particular experiment, 5ms delay target difference was enough to starve other flows (if I remember correctly 3ms was already sufficient, but below that LEDBAT there was no visible effect).

This translates to the following: if I, app developer number one, consider my application to be more important than any other background application, I add say 10 ms and will easily starve other apps. Joey Sixpack will not know the difference other than app one performs better than all the other ones. Mirja said earlier that that is only the case if two apps run behind the same bottleneck link. That's true but not uncommon. Ask yourself, how many people in your household access the net over the same home gateway. 

I guess our choice here is the following. Make it a SHOULD and you can have all sorts of apps running different delay targets one of which will win and this will be LEDBAT compliant behavior. Or, make it a MUST and all background apps are in the same boat, however you cannot explicitly prioritize one of those AND be LEDBAT compliant (I am not going to use the f******* word). This is for the group to figure out. Maybe in reality apps will do the former anyway. Then the difference is whether the app can claim to implement LEDBAT or not. 

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 Woundy, Richard
> Sent: Freitag, 9. Juli 2010 03:02
> To: Mirja Kühlewind; [email-masked]
> > If two different kind of applications are sharing the same bottleneck
> they might have different requirements for their transport and it might
> be the right thing that one app is raising the other.
> 
> My question would be, if there are two applications using two different
> delay targets, does the application with the higher delay target starve
> the application with the lower delay target?
> 
> -- Rich
>

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 9 Jul 2010 11:14:21 +0200

Hi,

>From my perspective, delay target adjustments are only marginally useful, as you really want to only add a certain amount of extra delay. Adjusting that based on the bandwidth doesn't make much sense as 25ms seconds on a high-speed link will have the same effect on your VoIP call as 25ms on your low-speed link. I am not quite sure why you want to make this dependent on your available bandwidth. Could you explain?

There obviously is a lower bound on the usefulness of blindly achieving a fixed delay target with respect to upstream bandwidth considering that a background transfer usually wants to transmit full-sized segments. In other words, if you have a large segment and it takes more than 25ms to send it out, then LEDBAT does not work unless you come up with a kind of adaptive segment-sizing mechanism. This is none trivial if multiple flows compete. BitTorrent Inc is working on something like this if I remember correctly and we had a shot at it but currently that effort rests.

The bandwidth range just after the above is tricky as you cannot transmit an awful lot of packets. After that you'll be fine and there is no real need to make special adjustments. 

Best,

	Rolf

> Behalf Of Mirja Kühlewind
> Sent: Donnerstag, 8. Juli 2010 18:03
> To: [email-masked]

---

From: Dario Rossi <[email-masked]>
Date: Mon, 12 Jul 2010 18:21:07 +0200

Hi all,

we have been repeating the experiments where we shown latecomer 
unfairness via *our own LEDBAT implementation via simulation*  ( ICCCN 
paper: 
http://perso.telecom-paristech.fr/~valenti/papers/ledbat-icccn10.pdf ), 
but this time using the *BitTorrent libUTP implementation in a LAN 
testbed* (logfiles of the experiments are in attach).

the figure reports the time evolution of the  cwnd on the top 
(y-axis=field #6 of the log file /1024 bytes) and the offset from the 
target at the bottom (column #5): the plot confirms that latecomer 
unfairness arise (at least, considering  backlogged flows), even when 
application choose the *same* target value (which is 100ms by default  
in BEP29 and in the libUTP implementation of LEDBAT at 
http://github.com/bittorrent/libutp)

so, although probably fairness is not the primary issue, we need to 
further differentiate two levels of unfairness:
* as discussed in the list, heterogeneous fixed target may indeed cause 
unfairness at flow-aggregate level (i.e., inter-peer of legacy application)
* besides, homogeneous fixed target can already cause unfairness at 
individual flow-level (i.e., intra-peer), caused by measurement errors 
and PID controller (as in the case shown by the picture)

thus, given the current congestion control, "delay target MUST/SHOULD" 
is maybe only part of the story (which we are currently digging further)

Best regards,
D.

On 07/09/2010 10:40 AM, Rolf Winter wrote:
>>> Should the delay target be MUST or SHOULD (or something else). There
>>>        
>> was a
>>      
>>> discussion on whether the delay target should be required to be 25ms.
>>>        
>> Stas
>>      
>>> argued it is needed for interoperability. But some people argued it
>>>        
>> would
>>      
>>> personally think this should be fixed. My argument would be that if
>>>        
>> people
>>      
>>> were allowed to fiddle with the 25 ms they will in order to have
>>>        
>> their app
>>      
>>> to perform better. Imagine two p2p applications running behind a
>>>        
>> common
>>      
>>> bottleneck (in your home network e.g.). The one choosing a slightly
>>>        
>> higher
>>      
>>> target will win over the other. We did experiments with this and
>>>        
>> found a
>>      
>>> few milliseconds to be sufficient. This potentially is an open
>>>        
>> invitation
>>      

-- 
        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: Joe Touch <[email-masked]>
Date: Wed, 14 Jul 2010 16:56:25 -0700

> My question would be, if there are two applications using two different delay targets, does the application with the higher delay target starve the application with the lower delay target?

This is my question as well; basically, whenever there is a MUST/SHOULD, 
it should be very clear what happens when it's not being followed.

If this is *required* for fairness, then that's reasonable. If not, then 
why is it there?

Joe

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 14 Jul 2010 23:50:48 -0700

On Jul 14, 2010, at 4:56 PM, Joe Touch wrote:

>> My question would be, if there are two applications using two  
>> different delay targets, does the application with the higher delay  
>> target starve the application with the lower delay target?
>
> This is my question as well; basically, whenever there is a MUST/ 
> SHOULD, it should be very clear what happens when it's not being  
> followed.
>
> If this is *required* for fairness, then that's reasonable. If not,  
> then why is it there?

Flows with higher targets will starve out flows with lower targets,  
which will only get a measurement trickle through.  This would seem to  
justify a MUST to me.

Something that occurs to me just now is that we could specify that the  
target MUST be no more than x and SHOULD be x, thus giving  
implementations the option to go with lower than the default LEDBAT  
priority.

Thoughts?

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Joe Touch <[email-masked]>
Date: Thu, 15 Jul 2010 09:54:34 -0700

On 7/14/2010 11:50 PM, Stanislav Shalunov wrote:
>> This is my question as well; basically, whenever there is a
>> MUST/SHOULD, it should be very clear what happens when it's not being
>> followed.
>>

That makes more sense. It explains the reason for the MUST and the SHOULD.

i.e., IMO, every MUST needs to explain how things basically won't work 
if it isn't followed, and every SHOULD needs to explain why it should be 
followed, the reasons for not following it, and the consequences that 
result.

Joe

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 16 Jul 2010 09:13:11 +0200

Hi,

This is acceptable, good actually. You can decide to be starved out but not starve others or else be not standards compliant. I assume x will remain 25ms?

Best,

	Rolf

> Behalf Of Joe Touch
> Sent: Donnerstag, 15. Juli 2010 18:55
> To: Stanislav Shalunov
> Cc: [email-masked]