[Cake] diffserv3 tin 2 target 50% of interval?

[Cake] diffserv3 tin 2 target 50% of interval?

[Pete Heist]

Hi, I’m finally getting to diffserv testing and am wondering about the tin 2 parameters of the default ‘diffserv3':

             Tin 0       Tin 1       Tin 2  
  thresh    3125Kbit      50Mbit   12500Kbit
  target       5.8ms       5.0ms       5.0ms
interval     100.8ms     100.0ms      10.0ms
Pk-delay         0us         0us         0us
Av-delay         0us         0us         0us
Sp-delay         0us         0us         0us
…

My understanding from the latest CoDel RFC: https://www.ietf.org/id/draft-ietf-aqm-codel-06.txt

and notes in the Overview section of this document from K. Nichols: http://www.pollere.net/Pdfdocs/noteburstymacs.pdf

are that ‘interval' should generally remain at 100ms and that ‘target' should be computed at around 5-10% of interval, and preferably closer to 5%.

In my testing, which I’ll release more results from soon, I’ve seen no significant benefit to changing target or interval from their defaults for either Wi-Fi or 100Mbit wired links. I question that lowering tin 2’s interval to 10ms provides any benefit, and in fact could very well cause undesired behavior for those using the defaults.

I could provide a spread of tests comparing ‘diffserv3' to ‘diffserv4’ for rrul at various bandwidths, but since ‘diffserv4’s tins all have standard 5/100 target and interval parameters, that seems preferable to the default of ‘diffserv3’. Is there a justification for setting the interval outside the guidelines suggested by CoDel’s authors?

Pete

Re: [Cake] diffserv3 tin 2 target 50% of interval?

[Jonathan Morton]

> ... ‘interval' should generally remain at 100ms and that ‘target' should be computed at around 5-10% of interval, and preferably closer to 5%.

> Is there a justification for setting the interval outside the guidelines suggested by CoDel’s authors?

The interval is reduced on Tin 2 because it is intended for latency-sensitive traffic, which merits a more aggressive AQM response than for best-effort traffic, which tends to be more throughput-sensitive.  This has the happy side-effect of giving an additional incentive to not use latency-sensitive DSCPs for bulk traffic.

It looks like you still aren’t using the latest version of tc, as that identifies the three tins as “Bulk”, “Best Effort”, and “Voice”, rather than numerically.

 - Jonathan Morton

Re: [Cake] diffserv3 tin 2 target 50% of interval?

[Pete Heist]

> On Feb 22, 2017, at 11:24 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> ... ‘interval' should generally remain at 100ms and that ‘target' should be computed at around 5-10% of interval, and preferably closer to 5%.
> 
>> Is there a justification for setting the interval outside the guidelines suggested by CoDel’s authors?
> 
> The interval is reduced on Tin 2 because it is intended for latency-sensitive traffic, which merits a more aggressive AQM response than for best-effort traffic, which tends to be more throughput-sensitive.  This has the happy side-effect of giving an additional incentive to not use latency-sensitive DSCPs for bulk traffic.
> 
> It looks like you still aren’t using the latest version of tc, as that identifies the three tins as “Bulk”, “Best Effort”, and “Voice”, rather than numerically.

Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as far as latency is concerned. I will make full results available later, but for now, here are two plots for the rrul test for diffserv3 and diffserv4, Cake on egress at 50Mbit between two Ethernet connected routers (no Wi-Fi):

http://www.drhleny.cz/bufferbloat/diffserv/rrul-rrul_cake_fd_50mbit-all_scaled.png (diffserv3)

http://www.drhleny.cz/bufferbloat/diffserv/rrul-rrul_cake_fd_50mbit_diffserv4-all_scaled.png (diffserv4)

Comparing the steady state portions of the plots for latency, they’re pretty much identical.

Also, shouldn't the EF flow (expedited forwarding) show lower latencies than BE (best effort)?

As for tc, I’m using the latest source from git://kau.toke.dk/cake/iproute2/, as per https://www.bufferbloat.net/projects/codel/wiki/Cake/. Shouldn't that be the latest or should I get it from somewhere else?

Pete

Re: [Cake] diffserv3 tin 2 target 50% of interval?

[Jonathan Morton]

> On 22 Feb, 2017, at 13:12, Pete Heist <peteheist@gmail.com> wrote:
> 
> Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as far as latency is concerned. I will make full results available later, but for now, here are two plots for the rrul test

The RRUL test, when viewed in Flent, only shows the latency induced by one flow (bulk) on another (ping).  This is influenced mainly by the flow-isolation and priority-queue mechanisms, not by AQM.

Where AQM helps is the effect of a flow on its *own* latency.  A bulk flow benefits relatively little from reduced latency, and mainly in the area of loss recovery; it also wants to operate in (or very near) the saturated regime as much as possible.  A latency-sensitive flow, by contrast, wants to avoid the saturated regime and its induced latency completely, and will accept higher packet loss to achieve that.

Cake keeps the inter-flow induced latency down to very near its theoretical minimum, given certain practical constraints such as timer and CPU-scheduling latency.  That’s mostly why you don’t see a latency difference in RRUL.  The other major factor is that RRUL loads all tins with bulk data, which means the Voice tin in particular is running in deprioritised mode.

 - Jonathan Morton

Re: [Cake] diffserv3 tin 2 target 50% of interval?

[Toke Høiland-Jørgensen]

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 22 Feb, 2017, at 13:12, Pete Heist <peteheist@gmail.com> wrote:
>> 
>> Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as
>> far as latency is concerned. I will make full results available later, but for
>> now, here are two plots for the rrul test
>
> The RRUL test, when viewed in Flent, only shows the latency induced by one flow
> (bulk) on another (ping). This is influenced mainly by the flow-isolation and
> priority-queue mechanisms, not by AQM.

Flent in git will capture the TCP RTT (using ss) and plot that as well;
you can try that out and see if you can measure a difference :)

-Toke

Re: [Cake] diffserv3 tin 2 target 50% of interval?

[Pete Heist]

> On Feb 22, 2017, at 12:32 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Jonathan Morton <chromatix99@gmail.com> writes:
> 
>>> On 22 Feb, 2017, at 13:12, Pete Heist <peteheist@gmail.com> wrote:
>>> 
>>> Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as
>>> far as latency is concerned. I will make full results available later, but for
>>> now, here are two plots for the rrul test
>> 
>> The RRUL test, when viewed in Flent, only shows the latency induced by one flow
>> (bulk) on another (ping). This is influenced mainly by the flow-isolation and
>> priority-queue mechanisms, not by AQM.
> 
> Flent in git will capture the TCP RTT (using ss) and plot that as well;
> you can try that out and see if you can measure a difference :)

Hi Toke, thanks for that, I’m finally getting around to using flent from source now, and saw the new plots: tcp_cwnd, tcp_rtt and tcp_rtt_cdf- then figured out they only work when the test is run with the —socket-stats flag. :)

They shouldn’t otherwise affect the results, right? Because I’d basically enable this for all of my flent runs.

Preliminarily, I _am_ seeing differences within TCP flows as the configuration is changed on my OM2P-HS / LEDE setup. There are some surprises, at least for me, but I’ll save the details until I post my second round of results because they require a lot of context, but hopefully these stats help give more insight into what’s going on. Thanks!

Re: [Cake] diffserv3 tin 2 target 50% of interval?

[Pete Heist]

> On Feb 22, 2017, at 12:24 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 22 Feb, 2017, at 13:12, Pete Heist <peteheist@gmail.com> wrote:
>> 
>> Ok, but for what it’s worth, so far I’m not seeing this confer any benefit as far as latency is concerned. I will make full results available later, but for now, here are two plots for the rrul test
> 
> The RRUL test, when viewed in Flent, only shows the latency induced by one flow (bulk) on another (ping).  This is influenced mainly by the flow-isolation and priority-queue mechanisms, not by AQM. Where AQM helps is the effect of a flow on its *own* latency.

Ok, so this might explain why I haven’t seen large latency differences between sfq and fq_codel or Cake in the RRUL test. There are some differences, but they’re higher at lower bitrates.

Still, shouldn’t the latency of EF compared to BE in the same test be lower, or not?

And where can I find the latest tc?