[tsvwg] draft-sporeba-tsvwg-mobile-l4s

[Chris Box <[e-mail]>]

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