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

[Ingemar Johansson S <[e-mail]>]

Hi
Inline..
Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 17 mars 2020 09:12
> To: Ingemar Johansson S <[e-mail]>
> Cc: Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>; Sebastian Moeller
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
> 
> > 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…
[IJ] ~10ms means roughly 10ms, could be 11.23342344354654667ms or 13.23423434423ms or 9.23423432434234ms ......

> 
> > 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.
[IJ] Please go ahead and experiment with SCReAM and SCE if you feel it's worth it. Personally I will not waste my precious brain cycles on SCE.

> 
>  - Jonathan Morton