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 protected]> 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 <[email protected]> *On Behalf Of *Alan Frindell > *Sent:* Wednesday, July 28, 2021 8:42 AM > *To:* [email protected]; [email protected]; QUIC WG <[email protected]>; [email protected] > *Cc:* Kirill Pugin <[email protected]> > *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 >
