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

From: Alan Frindell <[email-masked]>
Date: Wed, 28 Jul 2021 15:42:00 +0000

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

---

From: "Das, Dibakar" <[email-masked]>
Date: Wed, 28 Jul 2021 19:15:03 +0000

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

-Alan

---

From: Ian Swett <[email-masked]>
Date: Wed, 28 Jul 2021 15:41:59 -0400

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 <[email-masked]> wrote:

> 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.
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of *Alan Frindell
> *Sent:* Wednesday, July 28, 2021 8:42 AM
> *To:* [email-masked]; [email-masked]; QUIC WG <[email-masked]>; [email-masked]
> *Cc:* Kirill Pugin <[email-masked]>
> *Subject:* Reminder: Video Ingest over QUIC Side Meeting Friday 7/30
> 18:00 UTC
>
>
>
> Link to draft agenda and video conference details:
> https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md
>
>
>
> -Alan
>

---

From: "Das, Dibakar" <[email-masked]>
Date: Wed, 28 Jul 2021 20:17:31 +0000

Hi Ian,

Thanks for the response.

I think having some signaling visible to the network layer could be useful for the transmitter in the wireless link (say, an AP) as it can take this information into account while preparing the packets. It can even be used in current WiFi (i.e., with in-order delivery) to optimize its scheduling for that stream for example, it can send a Ctrl frame soon to clear holes in the reorder buffer at the recipient.

Regards,
Dibakar

From: Ian Swett <[email-masked]>
Sent: Wednesday, July 28, 2021 12:42 PM
To: Das, Dibakar <[email-masked]>
Cc: Alan Frindell <afrind=[email-masked]>; [email-masked]; [email-masked]; Kirill Pugin <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kirill, Alan,

Regards,
Dibakar

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

-Alan

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Jul 2021 20:23:56 +0000

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

Hi,

Ian

Regards,
Dibakar

-Alan

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Jul 2021 14:15:44 -0700

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=[email-masked]>
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.
>
>   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 <[email-masked]> on behalf of Ian Swett <ianswett=
> [email-masked]>
> *Date: *Wednesday, July 28, 2021 at 12:42 PM
> *To: *"Das, Dibakar" <[email-masked]>
> *Cc: *Alan Frindell <afrind=[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, Kirill Pugin <[email-masked]
> >
> *Subject: *Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30
> 18:00 UTC
>
>
>
> Hi,
>
>
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Jul 2021 21:41:31 +0000

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 <[email-masked]>
Date: Wednesday, July 28, 2021 at 2:16 PM
To: Roberto Peon <[email-masked]>
Cc: Ian Swett <[email-masked]>, "Das, Dibakar" <[email-masked]>, Alan Frindell <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Kirill Pugin <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> 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”.

-=R

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

Hi,

Ian

Regards,
Dibakar

-Alan

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 28 Jul 2021 18:53:01 -0500

Hi, Dibakar,

This is only my opinion, but this is a fine venue to ask questions. But it
may not be a good venue to resolve issues. Please take what follows as
suggestions.

There are people who understand some of the ins and outs of (for instance)
5G RAN, but honestly, there aren't a lot of them, so I'd start with 3GPP.

If this was a concern I had, the first place I'd stop is with Lionel Morand
([email-masked]), the 3GPP liaison to the IETF, to share this
concern. Lionel tends to be the person who sets agendas for the 3GPP-IETF
coordination team.

IETF participants are likely to say "if it hurts (performance) when you do
that, you probably should stop doing that". In my opinion, that's because
those participants don't want to special-case their protocols (especially
transport-level protocols) to deal with L2 characteristics that won't be
true for all underlying networking technologies.

The PILC working group, concluded about 20 years ago, put together a
nuanced discussion about L2 retransmissions in
https://datatracker.ietf.org/doc/html/rfc3819#section-8.1. If anyone in the
IETF thought that reasoning needed to be updated, I'd start with the TSVWG
chairs, at [email-masked] - I believe this would be in scope for
them, and Gorry Fairhurst, one of the RFC 3819 co-authors, is also a TSVWG
chair, so that would jumpstart things.

The current TSV ADs might have opinions about what should happen, but the
TSVWG co-chairs can involve them if they need to be involved.

I've taken the liberty of copying Lionel and the TSVWG chairs, so if you do
reach out to them, they'll know what you're talking about.

I hope this is helpful, and good luck on helping IETF and 3GPP Do The Right
Thing. I know that's important.

If I can explain any of this further, please email me privately, just to
minimize the hit on people's inboxes.

Best,

Spencer (full disclosure: I co-chaired PILC with Aaron Falk)

On Wed, Jul 28, 2021 at 3:17 PM Das, Dibakar <[email-masked]> wrote:

> Hi Ian,
>
>
>
> Thanks for the response.
>
>
>
> I think having some signaling visible to the network layer could be useful
> for the transmitter in the wireless link (say, an AP) as it can take this
> information into account while preparing the packets. It can even be used
> in current WiFi (i.e., with in-order delivery) to optimize its scheduling
> for that stream for example, it can send a Ctrl frame soon to clear holes
> in the reorder buffer at the recipient.
>
>
>
> Regards,
>
> Dibakar
>
>
>
>
>
> *From:* Ian Swett <[email-masked]>
> *Sent:* Wednesday, July 28, 2021 12:42 PM
> *To:* Das, Dibakar <[email-masked]>
> *Cc:* Alan Frindell <afrind=[email-masked]>; [email-masked];
> [email-masked]; Kirill Pugin <[email-masked]>
> *Subject:* Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30
> 18:00 UTC
>
>
>
> Hi,
>
>
>
> --
> Mops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mops
>

---

From: "Das, Dibakar" <[email-masked]>
Date: Thu, 29 Jul 2021 00:51:04 +0000

Hi Spencer,

Thank you for the detailed response as this is the sort of guidance I was looking for. Thank you also for the references.

Since the recommendation is to first raise the concern with layer-2 liaison, I will do that. However, I should clarify that I work on WiFi standards and not 3GPP. So, I will discuss the problem a bit more internally and then bring it up to the 802.11 liaison if needed.

Regards,
Dibakar

From: Spencer Dawkins at IETF <[email-masked]>
Sent: Wednesday, July 28, 2021 4:53 PM
To: Das, Dibakar <[email-masked]>
Cc: Ian Swett <[email-masked]>; Alan Frindell <afrind=[email-masked]>; [email-masked]; [email-masked]; Kirill Pugin <[email-masked]>; MORAND Lionel IMT/OLN <[email-masked]>; tsvwg-chairs <[email-masked]>
Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Hi, Dibakar,

This is only my opinion, but this is a fine venue to ask questions. But it may not be a good venue to resolve issues. Please take what follows as suggestions.

There are people who understand some of the ins and outs of (for instance) 5G RAN, but honestly, there aren't a lot of them, so I'd start with 3GPP.

If this was a concern I had, the first place I'd stop is with Lionel Morand ([email-masked]<mailto:[email-masked]>), the 3GPP liaison to the IETF, to share this concern. Lionel tends to be the person who sets agendas for the 3GPP-IETF coordination team.

IETF participants are likely to say "if it hurts (performance) when you do that, you probably should stop doing that". In my opinion, that's because those participants don't want to special-case their protocols (especially transport-level protocols) to deal with L2 characteristics that won't be true for all underlying networking technologies.

The PILC working group, concluded about 20 years ago, put together a nuanced discussion about L2 retransmissions in https://datatracker.ietf.org/doc/html/rfc3819#section-8.1. If anyone in the IETF thought that reasoning needed to be updated, I'd start with the TSVWG chairs, at [email-masked]<mailto:[email-masked]> - I believe this would be in scope for them, and Gorry Fairhurst, one of the RFC 3819 co-authors, is also a TSVWG chair, so that would jumpstart things.

The current TSV ADs might have opinions about what should happen, but the TSVWG co-chairs can involve them if they need to be involved.

I've taken the liberty of copying Lionel and the TSVWG chairs, so if you do reach out to them, they'll know what you're talking about.

I hope this is helpful, and good luck on helping IETF and 3GPP Do The Right Thing. I know that's important.

If I can explain any of this further, please email me privately, just to minimize the hit on people's inboxes.

Best,

On Wed, Jul 28, 2021 at 3:17 PM Das, Dibakar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ian,

Thanks for the response.

Regards,
Dibakar

From: Ian Swett <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 28, 2021 12:42 PM
To: Das, Dibakar <[email-masked]<mailto:[email-masked]>>
Cc: Alan Frindell <afrind=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kirill Pugin <[email-masked]<mailto:[email-masked]>>
Subject: Re: Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Hi,

Ian

Regards,
Dibakar

-Alan
--
Mops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mops

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 29 Jul 2021 11:53:08 +0000

Hi Dibakar,

Thanks for asking the question.

I think Spencer’s suggestion to involve 3GPP-IETF coordination team makes lots of sense here, hence I think you are on right track.

In my personal opinion, if a signaling helps that would be related to congestion control, recovery and ack signaling technique in use rather than specific to a particular protocol ( yes, QUIC comes with kind of right packaging of those techniques but those can be applied to other protocols as well). There are lot to discuss about it and requires right expertise ( I can always wish there is a single venue for that 😊).

BR
Zahed

On 2021-07-29, 06:51, "QUIC on behalf of Das, Dibakar" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Spencer,

Regards,
Dibakar

Hi, Dibakar,

Best,

Thanks for the response.

Regards,
Dibakar

Hi,

Ian

Regards,
Dibakar

Link to draft agenda and video conference details: https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md<https://protect2.fireeye.com/v1/url?k=00adeccc-5f36d5ca-00adac57-86ee86bd5107-7e78046795c61d1b&q=1&e=dbabf05d-73c5-47c7-b0be-c37322499476&u=https%3A%2F%2Fgithub.com%2Fafrind%2Fdraft-rush%2Fblob%2Fmain%2Fmeeting-materials%2Fagenda.2021.07.03.md>

-Alan

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 29 Jul 2021 10:08:49 -0500

Hi again, Dibakar,

On Thu, Jul 29, 2021 at 6:53 AM Zaheduzzaman Sarker <
[email-masked]> wrote:

> I think Spencer’s suggestion to involve 3GPP-IETF coordination team makes
> lots of sense here, hence I think you are on right track.
>

I saw your response about being an IEEE 802 guy, and not a 3GPP guy, but
had two thoughts.

   - If you think this is a problem for IEEE 802, there's also an IEEE
   802-IETF coordination team, and they meet regularly to talk about topics
   from one organization that are likely of interest to the other
   organization. That's a bit more visible to the community than the 3GPP-IETF
   coordination team, so you can get details here:
   https://www.iab.org/liaisons/iab-ieee-coordination/. Dorothy Stanley
   from IEEE 802.11 and Zahed Sarker, one of the TSV ADs, both, participate in
   those meetings, so the coordination chain from IEEE 802.11 to the IETF TSV
   area is pretty short. (I took the liberty of copying Dorothy on my email,
   again, so that she'll be in the loop if you pursue this in IEEE 802.11).
   - I understand about wanting to start in IEEE 802 where you're active,
   but I see that you're using an Intel email address, so you might want to
   also touch base with someone at one of the 15 Intel companies that are
   listed as members of 3GPP (here
   <https://webapp.etsi.org/3gppmembership/Results.asp?SortMember=Name&DirMember=ASC&SortPartner=Name&DirPartner=ASC&SortMarket=Name&DirMarket=ASC&SortObserver=Name&DirObserver=ASC&SortGuest=Name&DirGuest=ASC&Name=intel+&search=Search>),
   to see if they're as concerned about this as you are. I do participate in
   3GPP, so if you have problems figuring out who the actual Intel contacts
   are, please let me know privately, and I can see who attended recent
   meetings.

As Zahed said, we all wish for a single venue for discussions like this,
but maybe "three venues that communicate together well" could be a decent
substitute for that? 😀

Again, best wishes on this. It's an important discussion to have, just like
it was in the 1990s, and answers do change, even in the TSV area.

Best,

Spencer

> In my personal opinion, if a signaling helps that would be related to
> congestion control, recovery and ack signaling technique in use rather than
> specific to a particular protocol ( yes, QUIC comes with kind of right
> packaging of those techniques but those can be applied to other protocols
> as well). There are lot to discuss about it and requires right expertise (
> I can always wish there is a single venue for that 😊).
>
>
>
>
>
> BR
> Zahed
>
>
>
> On 2021-07-29, 06:51, "QUIC on behalf of Das, Dibakar" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Hi Spencer,
>
>
>
> Thank you for the detailed response as this is the sort of guidance I was
> looking for. Thank you also for the references.
>
>
>
> Since the recommendation is to first raise the concern with layer-2
> liaison, I will do that. However, I should clarify that I work on WiFi
> standards and not 3GPP. So, I will discuss the problem a bit more
> internally and then bring it up to the 802.11 liaison if needed.
>
>
>
> Regards,
>
> Dibakar
>
>
>
> *From:* Spencer Dawkins at IETF <[email-masked]>
> *Sent:* Wednesday, July 28, 2021 4:53 PM
> *Cc:* Ian Swett <[email-masked]>; Alan Frindell <afrind=
> [email-masked]>; [email-masked]; [email-masked]; Kirill Pugin <
> [email-masked]>; MORAND Lionel IMT/OLN <[email-masked]>;
> tsvwg-chairs <[email-masked]>
> *Subject:* Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting
> Friday 7/30 18:00 UTC
>
>
>
> Hi, Dibakar,
>
>
>
> If this was a concern I had, the first place I'd stop is with Lionel
> Morand ([email-masked]), the 3GPP liaison to the IETF, to share
> this concern. Lionel tends to be the person who sets agendas for the
> 3GPP-IETF coordination team.
>
>
>
> https://datatracker.ietf.org/doc/html/rfc3819#section-8.1. If anyone in
> the IETF thought that reasoning needed to be updated, I'd start with the
> TSVWG chairs, at [email-masked] - I believe this would be in scope
> for them, and Gorry Fairhurst, one of the RFC 3819 co-authors, is also a
> TSVWG chair, so that would jumpstart things.
>
>
>
> I've taken the liberty of copying Lionel and the TSVWG chairs, so if you
> do reach out to them, they'll know what you're talking about.
>
>
>
> <https://protect2.fireeye.com/v1/url?k=00adeccc-5f36d5ca-00adac57-86ee86bd5107-7e78046795c61d1b&q=1&e=dbabf05d-73c5-47c7-b0be-c37322499476&u=https%3A%2F%2Fgithub.com%2Fafrind%2Fdraft-rush%2Fblob%2Fmain%2Fmeeting-materials%2Fagenda.2021.07.03.md>
>
>
>
> -Alan
>
> --
> Mops mailing list
> [email-masked]

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 28 Jul 2021 22:57:28 +0000

And yet, we still can see network buffering to maintain packet ordering in new work today, including work specifically targeted at QUIC.

In the “CCID5” ANRW talk from Monday’s 2nd session, a reordering buffer was mentioned in the transparent proxy for the MP-DCCP tunnel they’re wrapping QUIC packets in to get multipath traffic-splitting during transport within wireless carriers (a proposal coming soon to tsvwg):
https://irtf.org/anrw/2021/program.html#:~:text=nathalie%20romo%20moreno

I asked specifically about the reordering buffer at the mic, since this kind of thing has made me sad before. (There was also a side discussion in the chat.)  I got the impression they believe they’re seeing some benefits to apps by including this reordering buffer in the network, citing the wider range of reordering that you get for split-path transport (as compared to the L2 forwarding case).

If there’s endpoint implementations that aren’t doing a good enough job here and therefore we’re seeing new network deployments that introduce buffering because their measurements indicate it’s helpful on common use cases, it could be worthwhile to get this straightened out before it gets too normalized and we start having networks reintroduce hol-blocking in a way that hurts some QUIC use cases in the name of helping others.

Although I expect this can and should be solved at the endpoints, if there is data showing that the ordering solves a real problem with current implementations, reasonable people can reasonably conclude that network buffering to maintain packet order is a good idea.

(Note: UDP client-side port might be an option for a network-visible signal that might “just work” for many (hopefully most?) ordering schemes to avoid buffering for ordering, but it might need some API support and it might lead to some other kinds of ugly nat problems if there’s too many flows doing it...)

+Anna, Nathalie and Markus.  Hopefully they can comment on this also.

Best,
Jake

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

David

-=R

Hi,

Ian

Regards,
Dibakar

Link to draft agenda and video conference details: https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md<https://urldefense.com/v3/__https:/github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md__;!!GjvTz_vk!E0SzSsjcIQqc-TDdIf5-y7XjoWfnEA-7r9fdRAjEKZXc1GYhGomlKIXMwmDZ0Ls$>

-Alan

---

From: Matt Joras <[email-masked]>
Date: Wed, 28 Jul 2021 16:58:06 -0700

Speaking as an individual, a couple comments inline adding to what Jake is
saying.

On Wed, Jul 28, 2021 at 3:58 PM Holland, Jake <jholland=
[email-masked]> wrote:

> And yet, we still can see network buffering to maintain packet ordering in
> new work today, including work specifically targeted at QUIC.
>
>
>
> In the “CCID5” ANRW talk from Monday’s 2nd session, a reordering buffer
> was mentioned in the transparent proxy for the MP-DCCP tunnel they’re
> wrapping QUIC packets in to get multipath traffic-splitting during
> transport within wireless carriers (a proposal coming soon to tsvwg):
>
> I asked specifically about the reordering buffer at the mic, since this
> kind of thing has made me sad before. (There was also a side discussion in
> the chat.)  I got the impression they believe they’re seeing some benefits
> to apps by including this reordering buffer in the network, citing the
> wider range of reordering that you get for split-path transport (as
> compared to the L2 forwarding case).
>

I would question whether any application-level benefits could be measured
by the network intermediaries. We (i.e., endpoint owners) have a hard
enough time surmising application-level improvements from _endpoint_
transport metrics, let alone trying to intuit those as a network
intermediary without any application context whatsoever. Making
network-level decisions based on limited information is a recipe for
"optimizations" that seem good on paper and for a limited set of metrics
but are worse in reality. This is exactly the kind of thing that has led to
the proliferation of TCP session terminating PEPs, which have overall been
a real impedance to making improvements with TCP on the Internet.

>
>
> If there’s endpoint implementations that aren’t doing a good enough job
> here and therefore we’re seeing new network deployments that introduce
> buffering because their measurements indicate it’s helpful on common use
> cases, it could be worthwhile to get this straightened out before it gets
> too normalized and we start having networks reintroduce hol-blocking in a
> way that hurts some QUIC use cases in the name of helping others.
>
>
>
> Although I expect this can and should be solved at the endpoints, if there
> is data showing that the ordering solves a real problem with current
> implementations, reasonable people can reasonably conclude that network
> buffering to maintain packet order is a good idea.
>

>
> (Note: UDP client-side port might be an option for a network-visible
> signal that might “just work” for many (hopefully most?) ordering schemes
> to avoid buffering for ordering, but it might need some API support and it
> might lead to some other kinds of ugly nat problems if there’s too many
> flows doing it...)
>
>
>
> *From: *David Schinazi <[email-masked]>
> *Date: *Wed,2021-07-28 at 2:16 PM
> *To: *Roberto Peon <[email-masked]>
> *Cc: *Ian Swett <[email-masked]>, "[email-masked]" <[email-masked]>,
> "Das, Dibakar" <[email-masked]>, Alan Frindell <[email-masked]>, "
> [email-masked]" <[email-masked]>, Kirill Pugin <[email-masked]>
> *Subject: *Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting
> Friday 7/30 18:00 UTC
>
>
>
> On Wed, Jul 28, 2021 at 1:24 PM Roberto Peon <fenix=
> [email-masked]> wrote:
>
> <https://urldefense.com/v3/__https:/github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md__;!!GjvTz_vk!E0SzSsjcIQqc-TDdIf5-y7XjoWfnEA-7r9fdRAjEKZXc1GYhGomlKIXMwmDZ0Ls$>
>
>
>
> -Alan
>
>

---

From: Anna Brunström <[email-masked]>
Date: Thu, 29 Jul 2021 00:30:45 +0000

I think multipath and L2 are a bit different as multipath may lead to large amounts of reordering and delay variations. Not all applications/implementations may handle this well. But you should of course also have the possibility to just pass the packets on, and I agree that in many cases this will be the best.

In the context of MP-DCCP, both scheduling and reordering are modular components so you can certainly choose to pass the packets on without delay. The need for supporting this is also stated in the draft. But for the multipath case, I think it is useful to also have the ability to reduce reordering if needed. For ATSSS I guess weather that is desirable or not may be controlled by the selected mode.

@Jake: if you understood our conversation in ANRW as suggesting that MP-DCCP should always reorder, that was a misunderstanding.

Best,
Anna

From: Matt Joras <[email-masked]>
Sent: den 29 juli 2021 01:58
To: Holland, Jake <jholland=[email-masked]>
Cc: David Schinazi <[email-masked]>; Roberto Peon <[email-masked]>; Anna Brunström <[email-masked]>; [email-masked]; [email-masked]; Ian Swett <[email-masked]>; [email-masked]; Das, Dibakar <[email-masked]>; Alan Frindell <[email-masked]>; [email-masked]; Kirill Pugin <[email-masked]>
Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Speaking as an individual, a couple comments inline adding to what Jake is saying.

On Wed, Jul 28, 2021 at 3:58 PM Holland, Jake <jholland=[email-masked]<mailto:[email-masked]>> wrote:
And yet, we still can see network buffering to maintain packet ordering in new work today, including work specifically targeted at QUIC.

I would question whether any application-level benefits could be measured by the network intermediaries. We (i.e., endpoint owners) have a hard enough time surmising application-level improvements from _endpoint_ transport metrics, let alone trying to intuit those as a network intermediary without any application context whatsoever. Making network-level decisions based on limited information is a recipe for "optimizations" that seem good on paper and for a limited set of metrics but are worse in reality. This is exactly the kind of thing that has led to the proliferation of TCP session terminating PEPs, which have overall been a real impedance to making improvements with TCP on the Internet.

Best,
Jake

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

David

-=R

Hi,

Ian

Regards,
Dibakar

-Alan

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://www.kau.se/gdpr>.
When you send an e-mail to Karlstad University, we will process your personal data<https://www.kau.se/en/gdpr>.

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 29 Jul 2021 00:40:36 +0000

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,
Jake

From: Anna Brunström <[email-masked]>
Date: Wed,2021-07-28 at 5:31 PM
To: Matt Joras <[email-masked]>, "Holland, Jake" <[email-masked]>
Cc: David Schinazi <[email-masked]>, Roberto Peon <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Ian Swett <[email-masked]>, "[email-masked]" <[email-masked]>, "Das, Dibakar" <[email-masked]>, Alan Frindell <[email-masked]>, "[email-masked]" <[email-masked]>, Kirill Pugin <[email-masked]>
Subject: RE: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Best,
Anna

In the “CCID5” ANRW talk from Monday’s 2nd session, a reordering buffer was mentioned in the transparent proxy for the MP-DCCP tunnel they’re wrapping QUIC packets in to get multipath traffic-splitting during transport within wireless carriers (a proposal coming soon to tsvwg):
https://irtf.org/anrw/2021/program.html#:~:text=nathalie%20romo%20moreno<https://urldefense.com/v3/__https:/irtf.org/anrw/2021/program.html*:*:text=nathalie*20romo*20moreno__;I34lJQ!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmh1HJdILQ$>

Best,
Jake

David

-=R

Hi,

Ian

Regards,
Dibakar

-Alan

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://urldefense.com/v3/__https:/www.kau.se/gdpr__;!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmhpcriyO0$>.
When you send an e-mail to Karlstad University, we will process your personal data<https://urldefense.com/v3/__https:/www.kau.se/en/gdpr__;!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmhrH9ZMhY$>.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 29 Jul 2021 18:32:56 +0200

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=
[email-masked]> escribió:

> 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,
>
> Jake
>
>
>
> *From: *Anna Brunström <[email-masked]>
> *Date: *Wed,2021-07-28 at 5:31 PM
> *To: *Matt Joras <[email-masked]>, "Holland, Jake" <
> [email-masked]>
> *Cc: *David Schinazi <[email-masked]>, Roberto Peon <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Ian Swett <[email-masked]>, "[email-masked]"
> <[email-masked]>, "Das, Dibakar" <[email-masked]>, Alan Frindell <
> [email-masked]>, "[email-masked]" <[email-masked]>, Kirill Pugin <[email-masked]
> >
> *Subject: *RE: [Mops] Reminder: Video Ingest over QUIC Side Meeting
> Friday 7/30 18:00 UTC
>
>
>
> I think multipath and L2 are a bit different as multipath may lead to
> large amounts of reordering and delay variations. Not all
> applications/implementations may handle this well. But you should of course
> also have the possibility to just pass the packets on, and I agree that in
> many cases this will be the best.
>
>
>
> In the context of MP-DCCP, both scheduling and reordering are modular
> components so you can certainly choose to pass the packets on without
> delay. The need for supporting this is also stated in the draft. But for
> the multipath case, I think it is useful to also have the ability to reduce
> reordering if needed. For ATSSS I guess weather that is desirable or not
> may be controlled by the selected mode.
>
>
>
> @Jake: if you understood our conversation in ANRW as suggesting that
> MP-DCCP should always reorder, that was a misunderstanding.
>
>
>
> Best,
>
> Anna
>
>
>
>
>
> *From:* Matt Joras <[email-masked]>
> *Sent:* den 29 juli 2021 01:58
> *To:* Holland, Jake <jholland=[email-masked]>
> *Cc:* David Schinazi <[email-masked]>; Roberto Peon <
> [email-masked]>; Anna Brunström <[email-masked]>;
> [email-masked]; [email-masked]; Ian Swett <
> [email-masked]>; [email-masked]; Das, Dibakar <[email-masked]>;
> Alan Frindell <[email-masked]>; [email-masked]; Kirill Pugin <[email-masked]>
> <https://urldefense.com/v3/__https:/irtf.org/anrw/2021/program.html*:*:text=nathalie*20romo*20moreno__;I34lJQ!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmh1HJdILQ$>
>
>
>
> När du skickar e-post till Karlstads universitet behandlar vi dina
> personuppgifter
> <https://urldefense.com/v3/__https:/www.kau.se/gdpr__;!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmhpcriyO0$>
> .
> When you send an e-mail to Karlstad University, we will process your
> personal data
> <https://urldefense.com/v3/__https:/www.kau.se/en/gdpr__;!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmhrH9ZMhY$>
> .
> --
> Mops mailing list
> [email-masked]

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 29 Jul 2021 18:10:34 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> escribió:
Hi Anna,

Best,
Jake

From: Anna Brunström <[email-masked]<mailto:[email-masked]>>
Date: Wed,2021-07-28 at 5:31 PM
To: Matt Joras <[email-masked]<mailto:[email-masked]>>, "Holland, Jake" <[email-masked]<mailto:[email-masked]>>
Cc: David Schinazi <[email-masked]<mailto:[email-masked]>>, Roberto Peon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ian Swett <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Das, Dibakar" <[email-masked]<mailto:[email-masked]>>, Alan Frindell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kirill Pugin <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Best,
Anna

From: Matt Joras <[email-masked]<mailto:[email-masked]>>
Sent: den 29 juli 2021 01:58
To: Holland, Jake <jholland=[email-masked]<mailto:[email-masked]>>
Cc: David Schinazi <[email-masked]<mailto:[email-masked]>>; Roberto Peon <[email-masked]<mailto:[email-masked]>>; Anna Brunström <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ian Swett <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Das, Dibakar <[email-masked]<mailto:[email-masked]>>; Alan Frindell <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kirill Pugin <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

Best,
Jake

David

-=R

Hi,

Ian

Regards,
Dibakar

-Alan

---

From: Ian Swett <[email-masked]>
Date: Thu, 29 Jul 2021 22:42:15 -0400

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.

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 <
[email-masked]> 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" <
> [email-masked] on behalf of [email-masked]> 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?
>
>
>

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 30 Jul 2021 05:43:48 +0000

GREASE-reordering is a brilliant idea, +1 to that.  (Particularly for writes that need to be broken up into packets anyway, and probably also for anything still buffered when more writes come in.)

If the end result is that UDP 443 on server side is excluded from reordering buffers, that’s a clear win regardless of any other network decisions that may or may not happen.

Best regards,
Jake

From: Ian Swett <ianswett=[email-masked]>
Date: Thu,2021-07-29 at 7:43 PM
To: Zaheduzzaman Sarker <[email-masked]>
Cc: Sergio Garcia Murillo <[email-masked]>, "[email-masked]" <[email-masked]>, Roberto Peon <[email-masked]>, Matt Joras <[email-masked]>, "Das, Dibakar" <[email-masked]>, Alan Frindell <[email-masked]>, "[email-masked]" <[email-masked]>, Anna Brunström <[email-masked]>, David Schinazi <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Kirill Pugin <[email-masked]>
Subject: Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting Friday 7/30 18:00 UTC

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.

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<https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/Sum_of_normally_distributed_random_variables__;!!GjvTz_vk!CYEeHbhK7C7RyDCja4rhiCVtdTRzsDAvDFa_mKJVustvWtuOr6WXbuj53eCLHh4$>).  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 <[email-masked]<mailto:[email-masked]>> 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

Best,
Jake

Best,
Anna

Best,
Jake

David

-=R

Hi,

Ian

Regards,
Dibakar

-Alan

När du skickar e-post till Karlstads universitet behandlar vi dina personuppgifter<https://urldefense.com/v3/__https:/www.kau.se/gdpr__;!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmhpcriyO0$>.
When you send an e-mail to Karlstad University, we will process your personal data<https://urldefense.com/v3/__https:/www.kau.se/en/gdpr__;!!GjvTz_vk!AVpyqSAj3HYNjnpUTryB_6DdElZmzNy4D78JApMaTuSanBUHBhhvFtmhrH9ZMhY$>.
--
Mops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mops<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mops__;!!GjvTz_vk!CYEeHbhK7C7RyDCja4rhiCVtdTRzsDAvDFa_mKJVustvWtuOr6WXbuj51KXgZqY$>

---

From: "Ali C. Begen" <[email-masked]>
Date: Fri, 30 Jul 2021 12:26:53 +0300

> On Jul 30, 2021, at 5:42 AM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> 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.

Sure, but that assumes independent distributions which does not much apply in this case. But the point is still valid, there will likely be 1-2 problematic hops in the entire ~10-20 e2e path.

>  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.  

Yes.

> Obviously, link-layer error correction and other approaches which increase reliability without introducing delay are still welcome and valuable.

+1, though improved reliability almost always comes at the cost of increased delay (rtx, fec, etc.).

---

From: Ian Swett <[email-masked]>
Date: Fri, 30 Jul 2021 10:02:10 -0400

On Fri, Jul 30, 2021 at 5:27 AM Ali C. Begen <ali.begen=
[email-masked]> wrote:

> introduces the most variation that matters.
>
> Sure, but that assumes independent distributions which does not much apply
> in this case. But the point is still valid, there will likely be 1-2
> problematic hops in the entire ~10-20 e2e path.
>

Yes, assuming a normal distribution is almost certainly wrong, so I should
have apologized up front for that.  As long as the conclusion is valid for
any plausible set of distributions, we should be good.

>
> >  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.
>
> Yes.
>
> > Obviously, link-layer error correction and other approaches which
> increase reliability without introducing delay are still welcome and
> valuable.
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 30 Jul 2021 09:06:52 -0500

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

> 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

>> Jakean/listinfo/mops <https://www.ietf.org/mailman/listinfo/mops>
>>
>>