Subject: [ledbat] LEDBAT target delay ranges

From: "Joerg Wagner" <[email-masked]>
Date: Mon, 23 Nov 2009 15:37:33 +0100

Hello,

I was wondering why the draft (http://tools.ietf.org/html/draft-ietf-ledbat-congestion-00) requests a delay target of 25 ms for LEDBAT flows but the implementation within uTorrent aims at a target delay of 100 ms (http://bittorrent.org/beps/bep_0029.html), which effectively is quite unfair when run together with other LEDBAT-like implementations aiming at 25 ms. Fine-tuning 'background transfer priority' of different apps using the target delay seems rather a bad choice to me...

Thanks for some comments!

Regards!

Joerg Wagner

---

From: Stanislav Shalunov <[email-masked]>
Date: Wed, 25 Nov 2009 14:54:28 -0800

Joerg,

You're absolutely right about the importance of choosing the right  
value and sticking to it.

The 25ms and 100ms (and 50ms) are all values that have been used.   
There's a tradeoff between the delay increase vs ability to saturate  
the bottleneck in the presence of noise.  Obviously the document we  
produce should ultimately reflect the best choice of the value.  When  
I put 25ms down in this draft, best available to me data indicated it  
to be high enough to float above the noise.  The 100ms was the initial  
value used in a wide rollout (higher values are generally more stable,  
and this was chosen to be on the safe side).

If you were to run some tests with different values of the TARGET and  
report the results to the list, that'd give the WG more data to choose  
the right value. :-)

Thanks,  -- Stas

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

On Nov 23, 2009, at 6:37 AM, Joerg Wagner wrote:

> Hello,
>
> I was wondering why the draft (http://tools.ietf.org/html/draft-ietf-ledbat-congestion-00 
> ) requests a delay target of 25 ms for LEDBAT flows but the  
> implementation within uTorrent aims at a target delay of 100 ms (http://bittorrent.org/beps/bep_0029.html 
> ), which effectively is quite unfair when run together with other  
> LEDBAT-like implementations aiming at 25 ms. Fine-tuning 'background  
> transfer priority' of different apps using the target delay seems  
> rather a bad choice to me...
>
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat