[tsvwg] Re: [EXTERNAL] draft-sporeba-tsvwg-mobile-l4s

["Overcash, Michael (CCI-Atlanta)" <[e-mail]>]

Link-layers MUST NOT buffer inbound packets that are marked with ECT(1) or CE, or with DSCP 45. Instead they must present those packets immediately to the operating system in whichever order they arrive.

Layer 2 wireless protocols generally require a certain amount of buffering for things like FEC, de-interleaving, reliable delivery, etc. I don't think "immediately" is meaningful here. I like the original text better ... "imposes measurable latency". Even better would be a specific measurable latency target. Like "imposes no more than 50 microseconds of latency" or whatever.
--
Michael Overcash
Principal Architect, CPE Premises Engineering

From: Chris Box <[e-mail]>
Sent: Thursday, July 30, 2026 11:29 AM
To: [e-mail]
Subject: [EXTERNAL] [tsvwg] draft-sporeba-tsvwg-mobile-l4s

Hi everyone

Following the meeting I've read https://datatracker.ietf.org/doc/draft-sporeba-tsvwg-mobile-l4s/ and agree this is a topic it's important to work on. I have some specific feedback which is listed below.

Overall scope
I would prefer to see this document focus exclusively on the mobile device, and its operation over mobile and Wi-Fi. Do we really need to add a lot of text about mobile network operators? Doing so is clearly possible but it will significantly expand the document. And I would then wonder why we're not discussing Wi-Fi operators.

Section 2 (Host Operating System Requirements)
Within subsection 2.1 there's a requirement that lies outside the OS:
Link layers MUST respond to misbehaving stack as discussed in {#defense-against-misbehaving-traffic}.

So we ought to delete it. I suggest we replace it with
Any use of ECT(1) for queue-building traffic is likely to result in poor performance due to {#defense-against-misbehaving-traffic}.

Section 2.2.1 (TCP Per-network detection and latency mitigation)
This discusses "a possible strategy". We should iterate and define a recommended strategy, as this is a BCP. Let's try to be really clear to the implementors.

A host system that wants to be resilient to this MAY attempt a connectivity check to a known, L4S-supporting service.
I suggest part of the recommended strategy is that it always does so, but does so both with and without ECT(1). If Not-ECT succeeds but ECT(1) fails, L4S should be disabled on this network for a period of time. If they both fail, it means there is another issue so no conclusions can be drawn. The draft should point to a resource where known L4S services are listed.

Section 3.1 (Link-layer inbound packet reordering)
Agree this would benefit from referring to draft-white-intarea-reordering<https://datatracker.ietf.org/doc/draft-white-intarea-reordering/>.

L4S-aware protocol stacks MUST be prepared to receive out-of-order packets.

This is a host OS requirement (and for UDP, an application requirement), so should be moved to section 2.


Link-layers MUST NOT buffer inbound L4S packets in a way that imposes measurable latency to the protocol stack.
I suggest replacing this with:

Link-layers MUST NOT buffer inbound packets that are marked with ECT(1) or CE, or with DSCP 45. Instead they must present those packets immediately to the operating system in whichever order they arrive.



Of course a CE-marked packet could be classic ECN or L4S. In either case, I suggest it's better to deliver the packet immediately so that the signal can be acted on. If it arrives ahead of some ECT(0) packets, that's fine. A transport that is willing to initiate ECT(0) should be able to handle reordering.



Section 3.2 (Multi-Queue Scheduling and Bounded Latency Queueing)

This gives an example of a three queue system: low latency, high priority and low priority. I think it should actually recommend adding a low latency queue for each of the priority levels that might contain L4S or NQB traffic. So if a modem currently has two priority levels for internet traffic, then it needs to implement four queues. However if the high priority queue can never be used by internet traffic, then three queues would be the right number.


Link layers SHOULD ensure that the L4S queue does not starve the other queues

This assumes it is prioritised above the other queues, which is not a given. You recommend WFQ but my understanding of RFC9330 section 4.2 is that it's a choice between dual-queue coupled AQM and per-flow queues. I suspect the latter is quite difficult for a modem.

Section 3.4 (Uplink Active Queue Management (AQM))
There are some different cases to consider on the mobile device.
1. Mobile is a hotspot, with Wi-Fi being the next hop for the packet
In this scenario the phone is merely a router, and it should implement L4S CE marking if packets have waited too long.
2. Mobile is a hotspot, with an L4S-supporting mobile network being the next hop
Here the phone is also a router, however 3GPP have specified that the mobile network will apply CE marking if it believes the packet waited too long before it was able to be sent over the air. This either occurs directly in the gNB, or the gNB tells the UPF to apply the mark. It would not be helpful to the user to have double marking probability, so in this scenario we should prohibit CE marking by the mobile device.
3. Packets originated on the mobile device itself
This is the most common case. Stuart has described eloquently why uplink AQM is a poor design: section 8.3 of draft-cheshire-sbm-04<https://www.ietf.org/archive/id/draft-cheshire-sbm-04.html#name-superiority-of-direct-backp>
As a result, we should change this section to prohibit uplink AQM and CE marking, and instead use direct backpressure to the application via appropriate APIs.

Section 3.5 (Defense Against Misbehaving Traffic (Queue Protection))
The link-layer SHOULD monitor queue build-up and latency contributions of individual flows within the L4S queue.
Do link layers currently maintain per-flow state? If not, it's probably a large ask for them to start doing so.

Section 4 (On-Path Node Requirements)
I said I would prefer the document's scope to focus on the mobile device. If we end up agreeing that, then this section should make it clear that this is only referring to personal hotspot requirements.

In general I'm happy to see the draft and I'd like to contribute to it.

Chris