Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

[Spencer Dawkins at IETF <[e-mail]>]

Trimming down to just the mailing lists, because I was getting rejection
messages from AVTCORE because of too many addresses in To/CC ...

On Thu, Jul 29, 2021 at 9:43 PM Ian Swett <ianswett=
[e-mail]> wrote:

> TLDR: Ideally, handling reordering on the receiving host will
> reduce user latency and be cheaper for everyone.
>
> Changing the TCP ecosystem is slow, so I can't advise immediately doing
> this for TCP traffic, but doing this now for QUIC(and maybe documenting it
> in Manageability?) seems viable.  If we wait longer, the ecosystem will be
> ossified.  I'm not sure anyone is willing to introduce intentional
> reordering to GREASE the loss detection system and ensure implementations
> adapt, but I'll discuss if that's something we would do for some traffic
> when sending multi-packet bursts.
>
> I believe the vast majority of QUIC applications would benefit from
> increased reordering if it reduced latency and buffering.  In TCP, you can
> detect reordering from the sequence number.  But for QUIC, the metadata is
> encrypted, so a given network can only attempt to reduce reordering in a
> much narrower context, which is much less useful.  Add into that the fact
> you don't know the application, and the benefits of delaying packets within
> the network/path become even more difficult to reason about.
>

I utterly and completely agree with what Ian says here (and echo Jake's
subsequent +1), and I note that although we seem to be keeping "multipath
QUIC" on the QUIC back-burner, applications that manage multiple paths at
the application level, especially if those paths are largely divergent,
make those benefits even further more difficult to reason about.

So maybe "bringing on the grease for reordering" would be a great thing to
do, before the network elements start trying to be helpful.

Best,

Spencer


> To frame this in statistical terms, the sum of multiple normal
> distributions is a normal distribution with the sum of the means and a sum
> of the variances(
> https://en.wikipedia.org/wiki/Sum_of_normally_distributed_random_variables).
> Since the standard deviation is the square root of the variance, the
> standard deviation is dominated by the largest source of variation, and if
> each link introduces some variance, it's really only the one that
> introduces the most variation that matters.  Given no link knows whether
> it's the dominant source of variation on the path, I'd suggest every link
> pass along packets as soon as possible.  Obviously, link-layer error
> correction and other approaches which increase reliability without
> introducing delay are still welcome and valuable.
>
> Thanks, Ian
>
>
>
> On Thu, Jul 29, 2021 at 2:10 PM Zaheduzzaman Sarker <
> [e-mail]> wrote:
>
>> I would say this is not specific to media over QUIC. However, a potential
>> solution to this could boost the deployment of potential radio technologies
>> ( for example - Unacknowledgement Mode (UM) of RLC in cellular networks)
>> which might actually help low latency media usecases.
>>
>>
>>
>> BR
>>
>> Zahed
>>
>>
>>
>> On 2021-07-29, 22:35, "QUIC on behalf of Sergio Garcia Murillo" <
>> [e-mail] on behalf of [e-mail]>
>> wrote:
>>
>>
>>
>> Just for clarification, if this needs to be handled, this should be
>> handled at QUIC level and it is not an specific problem for the Media over
>> QUIC protocol, right?
>>
>>
>>
>> El jue., 29 jul. 2021 18:15, Holland, Jake <jholland=
>> [e-mail]> escribió:
>>
>> Hi Anna,
>>
>>
>>
>> (And replacing Nathalie’s email with the correct one, hopefully)
>>
>>
>>
>> That was not quite my understanding, no.  Sorry if I opened this
>> discussion poorly.  In Nathalie’s initial response, she clarified that it’s
>> configurable, including the option to disable the reordering buffer.
>>
>>
>>
>> However, I understood this as an option available to the service provider
>> operating the MP-DCCP split path proxies that tunnel the carried traffic,
>> not necessarily to the endpoints or the applications having their traffic
>> split.
>>
>>
>>
>> Depending on how it’s deployed, this may or may not be a problem for
>> particular endpoints, but I couldn’t tell if there was an obvious or easy
>> way for an application to select the use case (particularly one that is
>> just trying to use QUIC and transparently getting traffic-splitting
>> delivery) in a way that the operator will understand, so I thought it best
>> to raise the point for discussion.
>>
>>
>>
>> Best,
>>
>> Jakean/listinfo/mops <https://www.ietf.org/mailman/listinfo/mops>
>>
>>