Hi David,
In mobile networks the L2 transport block vary in size and can contain
only a small fraction of an IP packet or several 1500 bytes packets.
When filling the transport block you may have the chance to pack in the
beginning of the next arrived packet or a complete but smaller IP
packet. When the transport block can't be successfully transferred but
the next one is then this may create a sort of HoL blocking, e.g. the
remaining of the incomplete IP packet can't be forwarded until the
transport block is retransmitted.
Regards,
Roland
Am 7/28/2021 um 11:15 PM schrieb David Schinazi:
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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> on behalf of Ian Swett
<[email protected]
<mailto:[email protected]>>
*Date: *Wednesday, July 28, 2021 at 12:42 PM
*To: *"Das, Dibakar" <[email protected]
<mailto:[email protected]>>
*Cc: *Alan Frindell <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>,
"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>, Kirill Pugin <[email protected]
<mailto:[email protected]>>
*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 protected] <mailto:[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]
<mailto:[email protected]>> *On Behalf Of *Alan Frindell
*Sent:* Wednesday, July 28, 2021 8:42 AM
*To:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; QUIC WG <[email protected]
<mailto:[email protected]>>; [email protected] <mailto:[email protected]>
*Cc:* Kirill Pugin <[email protected] <mailto:[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
<https://github.com/afrind/draft-rush/blob/main/meeting-materials/agenda.2021.07.03.md>
-Alan
