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

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

Hi Jonathan
Please see inline
/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 17 mars 2020 05:19
> To: Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>
> Cc: Sebastian Moeller <[e-mail]>; Ingemar Johansson S
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [tsvwg] SCReAM (RFC8298) with CoDel-ECN and L4S
> 
> > On 10 Mar, 2020, at 11:04 pm, Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]> wrote:
> >
> > Attached is a simulation of the same simple bottleneck case with
target=1ms
> and interval=20ms.
> > Two ECN beta values : 0.8 and 0.6. A larger backoff (0.6) does actually
not
> improve things as the CWND reduction leads to that packets from the video
> coder are queued up in the RTP queue.
> > As you can see there is still a way to go to reach the L4S delays.
> >
> > Perhaps the SCReAM's response to CoDel - ECN marks can be optimized
> further, don't know, but I already spent a considerable time to try and
get where
> the code is now, and I spent a lot more time on this than I spent on the
response
> to the L4S signal.
> > My impression is that it is the fractional congestion signal with L4S
that makes
> it easier to get a good algorithm behavior (and I definitely believe that
there is
> room for improvement)
> 
> I had a look through this thread again, and I remembered something which
may
> be very relevant to put these results into context.  I think you are
making at least
> some of these tests with a 50fps video stream from a typical PAL-format
> camcorder, in which case the interval between frames is already 20ms.  The
top
> of the delay graph in the tightened Codel traces is only 50ms, and in the
originals
> is 100ms.
[IJ] 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)

> 
> I estimate the queue delay in the tightened Codel traces is approximately
10ms
> most of the time - only half a frame.  Is this actually noticeable to the
user?
> Perhaps this performance is already good enough.
> 
> I think this level of delay mostly results from the behaviour of your
pacing
> algorithm under bursty demand.  Codel deliberately tolerates a degree of
> burstiness, in the name of maintaining reasonable throughput on the
networks
> and traffic patterns found in the real world.  As long as the queue
empties below
> the target delay within the interval, Codel will not intervene - and at
the
> tightened settings, the interval is approximately the same as the video
> framerate, which seems entirely appropriate.
> 
> Something you could try is to partially simulate an SCE deployment, by
setting
> SCReAM into L4S mode and employing a Codel AQM set to, say, 25ms interval,
> 2.5ms target.  I think that might have interesting results.  This actually
represents
> the SCE portion of an AQM optimised for a 100ms path, but it's a
configuration
> that's quite well tested and should cope well with a bursty traffic load.
There
> are some differences between the L4S response algorithm and the ones we
use
> in SCE, but I think you should get good results with this combination.
[IJ] 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?. 
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've looked briefly at the code, and I think true SCE support could also
be
> implemented without difficulty; you already have sufficient ECN codepoint
> feedback from the receiver.  You would need to apply the L4S response (or
> something broadly equivalent) when noting ECT(1) codepoints, and the
> conventional Multiplicative Decrease response when noting CE codepoints.
> Obviously, this also means ECT(0) must be emitted at origin, not ECT(1).
> 
> I'd be happy to advise further on work in this direction, if you think
it's
> promising.
[IJ] Surely possible. But like said before, I am not going there. 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 . I'd rather spend my
time on improving SCReAM, or any other congestion control algorithm for low
latency steaming media to utilize the potential with L4S better. But the
SCReAM code is of course available for anybody who wants to with it in any
desired direction.

> 
>  - Jonathan Morton