[tsvwg] SCReAM does not burst traffic (was RE: L4S Issue #26: Q Protection: mandatory to Implement?)

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

A correction to statement #3 below.
Quote "...or when traffic demand is very bursty (eg. realtime video over
SCREAM)"
This is wrong

SCReAM implements packet pacing and does therefore not burst out the video
frames. 
The pacing rate is typically 1.25 times the nominal video bitrate, this
means that with a video coder running at 50fps (20ms between frames), one
frame is clocked out in ~20/1.25 =  16ms. This of course varies a bit as
video frames generally vary in size.

/Ingemar

> -----Original Message-----
> From: Jonathan Morton <[e-mail]>
> Sent: den 30 oktober 2020 18:07
> To: Bob Briscoe <[e-mail]>
> Cc: Sebastian Moeller <[e-mail]>; Ingemar Johansson S
> <ingemar.s.johansson=[e-mail]>; Ingemar Johansson S
> <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?
> 
> > On 29 Oct, 2020, at 8:19 pm, Bob Briscoe <[e-mail]> wrote:
> >
> > Maybe I need to spell this out. The DualQ qdisc was about modularity:
"Do
> one thing and do it well". it was designed as a module to introduce *one*
> feature: ultra-low delay, and avoid introducing *two* features at once
(i.e.
> avoid intervening in rate control).
> 
> Taking your advice, I'm going to focus on this one statement, and focus
well.
> 
> DualQ actually does three different things, each of them poorly:
> 
> 1: It divides traffic into two classes to apply differential service to
them, using
> an input signal that can be ambiguous (ie. CE codepoints could belong to
> either class).
> 
> 2: Traffic from each class is delivered with nearly strict priority to one
class,
> ostensibly in support of the latency goal of that class.  This abdicates
the
> attendant responsibility of sharing capacity equitably between traffic
classes.  I
> use the word "equitably" advisedly, rather than "equally", acknowledging
that
> there are several viewpoints on what is "equitable" in a differentiated-
> services context.
> 
> 3: It performs Active Queue Management, using an algorithm that has been
> shown to perform poorly on paths that have significant latency jitter (eg.
> WiFi), or when traffic demand is very bursty (eg. realtime video over
> SCREAM).  On short paths, the difference in effective path latency
combined
> with the equalising of congestion windows between the two traffic flows
> results in a large imbalance in throughput.
> 
> I agree that modularity is a good thing in engineering, but so many
> components of L4S rely on workarounds for each others' failings that I
don't
> think it is actually very modular at all.  By contrast, SCE is designed so
that any
> major part of it can be substituted with an improved version without
difficulty
> - where "improvement" can be interpreted many different ways in various
> contexts.
> 
>  - Jonathan Morton