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

[Roberto Peon <[e-mail]>]

I agree that most of the time we’d want to tell L2s to not reorder/HoL block because most of the time we’re using modern CCs that won’t treat short-interval reordered packets as loss.

OTOH, reordering isn’t the only behavior that is interesting or problematic.
For instance, doing path-segment retries without waiting for the whole-path RTT is a good thing, and we wouldn’t want to get rid of it. We’d see far more jitter without it.
As the path-segment latency becomes close to the whole-path latency, however, it stops being a good thing—the jitter isn’t reduced, and may be increased because the available BW is fluctuating down by the amount of the retries that are happening.

The L2 can’t do the right thing all the time with a single behavior.. because it doesn’t know what the application wants/needs/has done.
If we don’t think that L2s should do reordering, sure… but one way or another, if we’re to measure whether that hypothesis is correct, we need a bit somewhere that allows a choice between the old way and a new way.

-=R

From: David Schinazi <[e-mail]>
Date: Wednesday, July 28, 2021 at 2:16 PM
To: Roberto Peon <[e-mail]>
Cc: Ian Swett <[e-mail]>, "Das, Dibakar" <[e-mail]>, Alan Frindell <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Kirill Pugin <[e-mail]>
Subject: Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Why would we need a signal here? This applies to all traffic, be it TCP QUIC or anything else. Firmwares introducing latency to reorder packets was a reaction to bad implementations of TCP from a long time ago that have been fixed in systems that care about performance. In today's world, L2 is better off delivering any and all packets in the order they arrive instead of introducing buffer bloat.

David

On Wed, Jul 28, 2021 at 1:24 PM Roberto Peon <fenix=[e-mail]<mailto:[e-mail]>> wrote:
The ideal would be to have public bits that were intended to be interpreted by (as you say, visible to) those layers so any L2 could adapted appropriately without reinventing the wheel.
It isn’t just the local radio firmware that one needs to worry about—it is also the basestation(s) that may be “helping”.

Separately, but also important, is being able to get signals from the application about what tradeoffs should be at the network. I believe that this dovetails into many of the multipath issues, btw.

A couple potentially interesting params are:
  A bit to say please don’t HoL block
  Some kind of mechanism(s) to bound retries (e.g. “don’t retry bit”, but that is obviously not as expressive as throw out packet older than X microseconds)

-=R

From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Ian Swett <ianswett=[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 28, 2021 at 12:42 PM
To: "Das, Dibakar" <[e-mail]<mailto:[e-mail]>>
Cc: Alan Frindell <afrind=[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Kirill Pugin <[e-mail]<mailto:[e-mail]>>
Subject: Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Hi,

I can't answer for Alan, but my belief is yes.  Client wifi stacks sometimes also do some reordering(and introduce the corresponding latency), so if we could design an indication that in-order delivery has no value, it could be fairly widely applicable.

That being said, I don't know what the right mechanism is?  Would we need something visible to a network or can we get away with a socket option that propagates to the local 5G network or Wifi firmware when possible?

Ian

On Wed, Jul 28, 2021 at 3:15 PM Das, Dibakar <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kirill, Alan,

I could not attend the call this week and wont be able to attend this side meeting either.

But I had a general question about the performance of all such QUIC based protocols over wireless. Typically, the 5G and WiFI MAC layers deliver frames in-order which sort of recreates the HOL blocking problem at lower layers. I would expect this to in turn prevent the QUIC protocol to achieve its full performance gains at least in some congested network scenarios. Considering that in-order delivery is made optional in 5G PDCP, I was wondering if there could be a value to have some signaling defined in the QUIC (or RUSH ?) protocol that would allow lower layers to make better decision about whether to enable/disable in-order delivery for certain streams.

I apologize in advance if this is not the right venue to ask questions.

Regards,
Dibakar



From: QUIC <[e-mail]<mailto:[e-mail]>> On Behalf Of Alan Frindell
Sent: Wednesday, July 28, 2021 8:42 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; QUIC WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Kirill Pugin <[e-mail]<mailto:[e-mail]>>
Subject: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC / 11 Pacific

Link to draft agenda and video conference details: https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md

-Alan