Cake rtt configuration

1- I would like to know what would be the recommended RTT to use in an application where I have an RTT of 8ms?
2 - What would happen if I put the RTT below the application RTT?

Have a look at man tc-cake:

ROUND TRIP TIME PARAMETERS         top

       Active Queue Management (AQM) consists of embedding congestion
       signals in the packet flow, which receivers use to instruct
       senders to slow down when the queue is persistently occupied.
       CAKE uses ECN signalling when available, and packet drops
       otherwise, according to a combination of the Codel and BLUE AQM
       algorithms called COBALT.

       Very short latencies require a very rapid AQM response to
       adequately control latency.  However, such a rapid response tends
       to impair throughput when the actual RTT is relatively long.
       CAKE allows specifying the RTT it assumes for tuning various
       parameters.  Actual RTTs within an order of magnitude of this
       will generally work well for both throughput and latency
       management.

       At the 'lan' setting and below, the time constants are similar in
       magnitude to the jitter in the Linux kernel itself, so congestion
       might be signalled prematurely. The flows will then become sparse
       and total throughput reduced, leaving little or no back-pressure
       for the fairness logic to work against. Use the "metro" setting
       for local lans unless you have a custom kernel.

       rtt TIME
            Manually specify an RTT.

       datacentre
            For extremely high-performance 10GigE+ networks only.
       Equivalent to rtt 100us.

       lan
            For pure Ethernet (not Wi-Fi) networks, at home or in the
       office.  Don't use this when shaping for an Internet access link.
       Equivalent to rtt 1ms.

       metro
            For traffic mostly within a single city.  Equivalent to rtt
       10ms.

       regional
            For traffic mostly within a European-sized country.
       Equivalent to rtt 30ms.

       internet (default)
            This is suitable for most Internet traffic.  Equivalent to
       rtt 100ms.

       oceanic
            For Internet traffic with generally above-average latency,
       such as that suffered by Australasian residents.  Equivalent to
       rtt 300ms.

       satellite
            For traffic via geostationary satellites.  Equivalent to rtt
       1000ms.

       interplanetary
            So named because Jupiter is about 1 light-hour from Earth.
       Use this to (almost) completely disable AQM actions.  Equivalent
       to rtt 3600s.

So the way this works is codel derivative AQMs like cake will measure the sojourn time and if the sojourn stays above the delay 'target' for a configured 'interval' codel will schedule a signal (mark or drop) codel will then also calculate the next interval (shorter than the previous) so it will adapt ist signalling to the traffic responsiveness. For each flow the fastest time a reaction of the sent signal can become visible at the AQM is 1 round trip time, as the signal first travels to the receiver, is reflected back tor the sender the sender adapts its congestion window and hence its sending rate and that changes rate needs to propagate to the AQM location. If the codel interval is noticeably shorter than the RTT then codel will schedule more signals and hence instruct the flow to reduce its rate more than required. Ideally codel would know each flow's rtt and use that as interval for each flow, but that is not possible in a robust and reliable way, and so codel needs to operate with a single interval... If interval is (much) smaller than the true RTT of a flow and there is also a flow in the queue with a RTT smaller or equal to interval, the long RTT flow will get signalled harder and hence will get less than its equitable capacity share. As a rule of thumb 100ms is a decent proxy for 'internet' traffic that allows for flows crossing oceans, like europe to north amerika. Flow queuing Coddel variants like fq_codel or cake that isolate flows from each other are considerably less sensitive to interval being exact and will works well if interval is in the right order of magnitude.

In fq_codel both target and interval are exposed parameters, but as the CoDel RFC8289 explains, target should be in the range of 5-10% of interval to maximise network power; so cake only allows to configure the codel interval and calls this 'rtt', cake will then automatically calculate target as 5% of thge requested rtt.

So now on to your questions:

That depends on your goal, but if all traffic that a cake instance sees will have an RTT of 8ms, then setting the interval to 10-20ms will work and will signal each flow in a timely manner, longer then interval RTT flows over the same link however, if competing with lower RTT flows, will not get their fair capacity share (but see above, the interval/rtt setting only needs to match roughly)

You would schedule more signals (aka marks drops) and the flow might not reach its maximal bloat free throughput, but you will also see a smaller standing queue and jitter.

If in doubt, try it out...
For my use cases the default interval of 100ms works pretty well, but most/all of my latency sensitive flows are not capacity seeking in the first place and hence do not tend to self congest, and in cake/fq_codel the AQM part mostly addresses self congestion.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.