* [Codel] interval target relation ship question
@ 2014-03-13 8:41 Sebastian Moeller
2014-03-13 9:04 ` Andrew McGregor
0 siblings, 1 reply; 4+ messages in thread
From: Sebastian Moeller @ 2014-03-13 8:41 UTC (permalink / raw)
To: codel
Dear Experts,
Codel and especially fq_codel have massively improved snappiness/interactivity of typical residential internet connections, as shown in the cerowrt testbed and also in the french ISP free's roll-out of coddled xddl modems. One observation has been that at low bandwidth the latency/bandwidth trade-off does not seem to be ideal and an empirical solution to this problem has been to increase the target as a function of the available bandwidth. I realize that codel tries to accommodate for low-bandwidth links by always allowing at least one packet in the queue. But empirically that does not seem to be enough for good behavior on slow links (I think the issue is that the bandwidth sacrifice seems a bit to large)…
Currently we try to model what we know about free's approach in cerowrt, basically we increase target as a function of bandwidth and also increase interval be the same amount as target. Now having read section "3.2 Setpoint" of https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text=1 makes a strong point that target should be in the range of 5-10% of interval. So would it make more sense to increase interval so that after adjustments new_target = 0.05*new_interval still stays true? Or would you recommend to do something along the lines of:
new_interval = 100ms + known DSL link latency (can be in the range of dozens of ms)
new_target = new_interval * 0.05 or new_interval * 0.1
I guess I will try to actually test the different approaches in the near future, but would be delighted to get help establishing a decent hypothesis before hand which modification actually will work best.
Bet Regards
Sebastian
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Codel] interval target relation ship question
2014-03-13 8:41 [Codel] interval target relation ship question Sebastian Moeller
@ 2014-03-13 9:04 ` Andrew McGregor
2014-03-13 9:28 ` Sebastian Moeller
0 siblings, 1 reply; 4+ messages in thread
From: Andrew McGregor @ 2014-03-13 9:04 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: codel
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
My intuition suggests something like:
Target = 4ms + MTU sized packet duration
Interval = target * 20
(But only if the resulting interval is more than 100ms)
Possibly the packet duration may need a small factor (2 or 3) to get the
balance right.
On 13 Mar 2014 19:41, "Sebastian Moeller" <moeller0@gmx.de> wrote:
> Dear Experts,
>
> Codel and especially fq_codel have massively improved
> snappiness/interactivity of typical residential internet connections, as
> shown in the cerowrt testbed and also in the french ISP free's roll-out of
> coddled xddl modems. One observation has been that at low bandwidth the
> latency/bandwidth trade-off does not seem to be ideal and an empirical
> solution to this problem has been to increase the target as a function of
> the available bandwidth. I realize that codel tries to accommodate for
> low-bandwidth links by always allowing at least one packet in the queue.
> But empirically that does not seem to be enough for good behavior on slow
> links (I think the issue is that the bandwidth sacrifice seems a bit to
> large)...
> Currently we try to model what we know about free's approach in
> cerowrt, basically we increase target as a function of bandwidth and also
> increase interval be the same amount as target. Now having read section
> "3.2 Setpoint" of
> https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text=1makes a strong point that target should be in the range of 5-10% of
> interval. So would it make more sense to increase interval so that after
> adjustments new_target = 0.05*new_interval still stays true? Or would you
> recommend to do something along the lines of:
> new_interval = 100ms + known DSL link latency (can be in the range
> of dozens of ms)
> new_target = new_interval * 0.05 or new_interval * 0.1
>
> I guess I will try to actually test the different approaches in the near
> future, but would be delighted to get help establishing a decent hypothesis
> before hand which modification actually will work best.
>
>
> Bet Regards
> Sebastian
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
[-- Attachment #2: Type: text/html, Size: 2858 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Codel] interval target relation ship question
2014-03-13 9:04 ` Andrew McGregor
@ 2014-03-13 9:28 ` Sebastian Moeller
2014-03-13 16:02 ` Kathleen Nichols
0 siblings, 1 reply; 4+ messages in thread
From: Sebastian Moeller @ 2014-03-13 9:28 UTC (permalink / raw)
To: Andrew McGregor; +Cc: codel
Hi Andrew,
On Mar 13, 2014, at 10:04 , Andrew McGregor <andrewmcgr@gmail.com> wrote:
> My intuition suggests something like:
> Target = 4ms + MTU sized packet duration
> Interval = target * 20
The current version just does MTU plus overhead packet duration (basically taking 1544 as maximal DSL packet size, it is not that this needs to be precise to the last bit) and does interval = interval + target - 5ms, so basically it increases target and interval by the same amount (note we take the maximum of the calculated argot and 5ms), Where does your 4ms come from?
I wonder whether the important step is increasing the target or wether it is to change the ratio of interval and target (the current method basically does both).
Thanks for your input
best regards
Sebastian
>
> (But only if the resulting interval is more than 100ms)
>
> Possibly the packet duration may need a small factor (2 or 3) to get the balance right.
>
> On 13 Mar 2014 19:41, "Sebastian Moeller" <moeller0@gmx.de> wrote:
> Dear Experts,
>
> Codel and especially fq_codel have massively improved snappiness/interactivity of typical residential internet connections, as shown in the cerowrt testbed and also in the french ISP free's roll-out of coddled xddl modems. One observation has been that at low bandwidth the latency/bandwidth trade-off does not seem to be ideal and an empirical solution to this problem has been to increase the target as a function of the available bandwidth. I realize that codel tries to accommodate for low-bandwidth links by always allowing at least one packet in the queue. But empirically that does not seem to be enough for good behavior on slow links (I think the issue is that the bandwidth sacrifice seems a bit to large)…
> Currently we try to model what we know about free's approach in cerowrt, basically we increase target as a function of bandwidth and also increase interval be the same amount as target. Now having read section "3.2 Setpoint" of https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text=1 makes a strong point that target should be in the range of 5-10% of interval. So would it make more sense to increase interval so that after adjustments new_target = 0.05*new_interval still stays true? Or would you recommend to do something along the lines of:
> new_interval = 100ms + known DSL link latency (can be in the range of dozens of ms)
> new_target = new_interval * 0.05 or new_interval * 0.1
>
> I guess I will try to actually test the different approaches in the near future, but would be delighted to get help establishing a decent hypothesis before hand which modification actually will work best.
>
>
> Bet Regards
> Sebastian
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Codel] interval target relation ship question
2014-03-13 9:28 ` Sebastian Moeller
@ 2014-03-13 16:02 ` Kathleen Nichols
0 siblings, 0 replies; 4+ messages in thread
From: Kathleen Nichols @ 2014-03-13 16:02 UTC (permalink / raw)
To: codel
Hi, Sebastian,
My "best guess" is that increasing your interval to cover the DSL
latency and packet
duration is the significant step since the "don't starve the link" drop
inhibit should
dominate the target. That said, I would set the target to be .05 to .1
of that interval,
possibly pushing more to the .1 for consistency.
Something that could use further study is whether to inhibit drops or
cancel the drop
state when a drop would leave the queue empty. That is, it would be good
to do a
comparison with real traffic in a real network.
Kathie
On 3/13/14 2:28 AM, Sebastian Moeller wrote:
> Hi Andrew,
>
>
> On Mar 13, 2014, at 10:04 , Andrew McGregor <andrewmcgr@gmail.com>
> wrote:
>
>> My intuition suggests something like: Target = 4ms + MTU sized
>> packet duration Interval = target * 20
>
> The current version just does MTU plus overhead packet duration
> (basically taking 1544 as maximal DSL packet size, it is not that
> this needs to be precise to the last bit) and does interval =
> interval + target - 5ms, so basically it increases target and
> interval by the same amount (note we take the maximum of the
> calculated argot and 5ms), Where does your 4ms come from? I wonder
> whether the important step is increasing the target or wether it is
> to change the ratio of interval and target (the current method
> basically does both).
>
> Thanks for your input
>
> best regards Sebastian
>
>>
>> (But only if the resulting interval is more than 100ms)
>>
>> Possibly the packet duration may need a small factor (2 or 3) to
>> get the balance right.
>>
>> On 13 Mar 2014 19:41, "Sebastian Moeller" <moeller0@gmx.de> wrote:
>> Dear Experts,
>>
>> Codel and especially fq_codel have massively improved
>> snappiness/interactivity of typical residential internet
>> connections, as shown in the cerowrt testbed and also in the french
>> ISP free's roll-out of coddled xddl modems. One observation has
>> been that at low bandwidth the latency/bandwidth trade-off does not
>> seem to be ideal and an empirical solution to this problem has been
>> to increase the target as a function of the available bandwidth. I
>> realize that codel tries to accommodate for low-bandwidth links by
>> always allowing at least one packet in the queue. But empirically
>> that does not seem to be enough for good behavior on slow links (I
>> think the issue is that the bandwidth sacrifice seems a bit to
>> large)… Currently we try to model what we know about free's
>> approach in cerowrt, basically we increase target as a function of
>> bandwidth and also increase interval be the same amount as target.
>> Now having read section "3.2 Setpoint" of
>> https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/?include_text=1
>> makes a strong point that target should be in the range of 5-10% of
>> interval. So would it make more sense to increase interval so that
>> after adjustments new_target = 0.05*new_interval still stays true?
>> Or would you recommend to do something along the lines of:
>> new_interval = 100ms + known DSL link latency (can be in the range
>> of dozens of ms) new_target = new_interval * 0.05 or new_interval *
>> 0.1
>>
>> I guess I will try to actually test the different approaches in the
>> near future, but would be delighted to get help establishing a
>> decent hypothesis before hand which modification actually will work
>> best.
>>
>>
>> Bet Regards Sebastian
>> _______________________________________________ Codel mailing list
>> Codel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/codel
>
> _______________________________________________ Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-13 16:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-13 8:41 [Codel] interval target relation ship question Sebastian Moeller
2014-03-13 9:04 ` Andrew McGregor
2014-03-13 9:28 ` Sebastian Moeller
2014-03-13 16:02 ` Kathleen Nichols
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox