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

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

Hi again, Dibakar,

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

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

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" <
> [e-mail] on behalf of [e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, July 28, 2021 4:53 PM
> *To:* Das, Dibakar <[e-mail]>
> *Cc:* Ian Swett <[e-mail]>; Alan Frindell <afrind=
> [e-mail]>; [e-mail]; [e-mail]; Kirill Pugin <
> [e-mail]>; MORAND Lionel IMT/OLN <[e-mail]>;
> tsvwg-chairs <[e-mail]>
> *Subject:* Re: [Mops] Reminder: Video Ingest over QUIC Side Meeting
> Friday 7/30 18:00 UTC
>
>
>
> Hi, Dibakar,
>
>
>
> I apologize in advance if this is not the right venue to ask questions.
>
>
>
> 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 ([e-mail]), 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 [e-mail] - 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 <[e-mail]>
> 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 <[e-mail]>
> *Sent:* Wednesday, July 28, 2021 12:42 PM
> *To:* Das, Dibakar <[e-mail]>
> *Cc:* Alan Frindell <afrind=[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
>
>
>
> 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]>
> 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]> *On Behalf Of *Alan Frindell
> *Sent:* Wednesday, July 28, 2021 8:42 AM
> *To:* [e-mail]; [e-mail]; QUIC WG <[e-mail]>; [e-mail]
> *Cc:* Kirill Pugin <[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
> <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mops
>
>