Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S

[Jonathan Morton <[e-mail]>]

> On 17 Mar, 2020, at 9:02 am, Ingemar Johansson S <[e-mail]> wrote:
> 
> The frame rate in this example is 60fps, which means a 16.6ms frame
> interval. I am not convinced though that the frame rate plays so much role
> here as the packet pacing make these 16.6ms frames become transmitted in
> ~10ms or so (depends in the computed pacing rate in SCReAM)

Hmm, takes 10ms to transmit the frame, results in 10ms peak queuing latency, on a 20ms baseline path.  Seems like an awfully big coincidence to me.  All joking aside…

> Yes, possible that it may be as you say, but doesn't this reveal a flaw
> in CoDel if you need to adapt thresholds based on assumptions on application
> layer behavior?

No, because that's not what we're making assumptions about when choosing Codel parameters.  It just so happens that your baseline path RTT and framerate are conveniently similar, but the typical path RTT is what Codel is supposed to be tuned for.  The default parameters, with a 100ms interval, are intended for use on general Internet paths with conventional AIMD traffic.

The 25/2.5ms parameters are what we are already using for high-fidelity congestion control in much of our SCE testing.  They are not tuned for your particular application.  I'm just curious how it would react, with the L4S-type response, if given that style of signalling.  No code changes are needed to try this out.

> I cannot for instance rule out that somebody in the future (or perhaps
> already now?) implements a gaming engine that updates part of the view with
> 240fps and other, less important parts with 30fps. QUIC would allow all that
> media over one connection but in different streams. For the network it would
> just be a bunch of packets passing through.

I imagine such a stream would have more frequent cycling and relatively smaller peaks of traffic.  This would make the problem slightly easier, not harder, from a queuing point of view.

> I don't see that it is worth spending effort on this as it should be apparent by now that SCE would not give better performance than L4S.


When the traffic is not bursty and does not exhibit a significant sawtooth structure, the difference between controlling the peak or the trough of the traffic is minor.  However, SCReAM presently does not fit that description.

To a great extent, L4S' aggressive marking strategy ends up controlling the peaks of the traffic, while Codel tends to control the troughs.  When applied to SCReAM traffic, the latter results in noticeably higher throughput - which I presume corresponds to better image quality - than the former.  It does do while still controlling the added delay to less than one frame time, except during the exceptional event of the sharp reduction in capacity.

SCE is designed to be safe to use over existing Internet paths.  L4S, as presently implemented, is not.  That's a point which might not show up on a raw performance comparison, in which traffic is run only through nodes which fully implement the new specification.  It is of course possible to employ L4S' aggressive signalling schedule using the SCE method.  This gets you the same performance as L4S on a conforming network, but also keeps you compatible with conventional networks by retaining the standard meaning of a CE mark.

So I'm not certain what metrics you're using which say L4S outperforms SCE here, but since we are using Codel for SCE marking, I'd say the above characteristics are at least worthy of further study.  Of course I can't insist on it, but I think it would save some time and effort in the long run.

Separately, I also think that if you were to make the pacing rate and target encoding rate more similar (as the encoder seems to track the latter pretty closely), that would improve SCReAM's performance on both L4S and SCE - for different reasons.  Both stem from the fact that your data-in-flight number currently fluctuates a lot on short timescales, and on average is much less than the cwnd.

In the case of L4S, you would get a straightforward increase in throughput and thus image quality from what you presently have.

In the case of Codel-based marking, there would be less noise in the queue-depth signal, resulting in a better estimate of the true BDP being represented in the cwnd, and better control of the network side of the delay equation. As I understand it, SCReAM is designed so that data still in the application-side buffer can be discarded to accelerate recovery when network conditions abruptly change, and this would facilitate that.  The result should be roughly equal throughput but improved delay characteristics.

But until it's tested, those are just my educated guesses.  I think SCReAM-like traffic would be a valuable addition to our test suite, but it will take time to figure out how to integrate it - since it's written in a different language than we normally use.

 - Jonathan Morton