Re: [tsvwg] start of WGLC on L4S drafts

["Holland, Jake" <[e-mail]>]

Overall:
The documents are in much better shape than the last time I reviewed
them, thanks for all the improvements.

I'm reviewing l4s-id and l4s-arch but didn't have time to get to
dualq-aqm yet.  But I wanted to make sure these got posted, and
might not have more time before the deadline.

----

draft-ietf-tsvwg-ecn-l4s-id-19:
There's a few major issues.  These really should be fixed before
sending it to the IESG, IMO, but with these fixed I'd be happy to
see it shipped.

Major:

1. This should be proposed standard, not experimental.

This assigns a new and incompatible meaning to an IP header codepoint
in a way that can't be rolled back or kept isolated, with declared
intent to roll it out widely.  This should be considered a proposed
standard action and make an update to RFCs 3168 and 8311 that clearly
states that any existing marking queues should be changed where
possible to treat ECT(1) as either L4S or Not-ECT, even if the device
is not participating in an L4S-related experiment.

Such an update would align the specs with the stated expectations
that monitoring requirements should be in place mainly as a legacy
workaround, and would provide appropriate and potentially actionable
standards track mitigations that are available to on-path devices
implicated in any problems that are observed, whereas the specs as
currently written have none.

I understand that RFC 8311 was originally intended to cover this, but
that was published back when the L4S proposal still intended to make
the ECT(1)-marking compatible with classic marking via a robust
detection scheme, and RFC 8311 embeds that assumption throughout.  Now
that the proposal has changed to rolling this out without solving the
coexistence problem, RFC 8311's provisions are no longer adequate to
cover this IMO, and must be updated if we intend to have a self-
consistent set of specs published.

(Alternately, a separate standards-track doc could recommend changing
ECT(1) handling to Not-ECT, but I really think there's no point
separating them, and such a doc would still have to be a prerequisite
for moving this forward IMO.  I suggest that the most expedient
path as well as the better choice here is to make l4s-id standards
track and to add the Not-ECT option for ECT(1) here as a reasonable
problem mitigation strategy available to marking bottlenecks.)

2. This text from Section 4.3 should be strengthened to recommend
detection of paths that might be classic-marking L4S traffic (shared
queue or not):

   o  In uncontrolled environments, monitoring MUST be implemented to
      support detection of problems with an ECN-capable AQM at the path
      bottleneck that appears not to support L4S and might be in a
      shared queue.

Even in fq, the standing queue that will be built by a scalable cc with
classic marking is contrary to "1-2ms latency at 99th percentile" goal
of L4S, even leaving aside the harm to colliding flows (though of course
the harm to colliding flows, including from hash collisions in fq, is
also another reason to make this change).

3. This text from Section 4.3 should be strengthened to require that
sending L4S traffic in uncontrolled environments does not happen when
classic marking of L4S traffic is detected for a shared queue, and at
least recommend that it not happen even for fq:

   o  In uncontrolled environments, monitoring MUST be implemented to
      support detection of problems with an ECN-capable AQM at the path
      bottleneck that appears not to support L4S and might be in a
      shared queue.  Such monitoring SHOULD be applied to live traffic
      that is using Scalable congestion control.  Alternatively,
      monitoring need not be applied to live traffic, if monitoring has
      been arranged to cover the paths that live traffic takes through
      uncontrolled environments. 

The current text requires monitoring, but only gives a single SHOULD for
live traffic, plus non-normatively permits one alternative.  This allows
operators to monitor but not cut off (so this requirement as currently
written would be satisfied by write-only logging for instance, with the
SHOULD easily dismissable with an "implementation complexity" hand-wave
while still following the spec).

Suggested alternative, feel free to edit:

   o  In uncontrolled environments, L4S traffic MUST NOT be sent without
      monitoring to detect marking of L4S traffic by non-L4S bottlenecks.
      This monitoring can for example be performed on live traffic, or
      can rely on monitoring that covers the paths live traffic takes
      through uncontrolled environments.  Where non-L4S bottlenecks are
      observed marking L4S traffic, L4S sending MUST be disabled if the
      bottleneck is a shared queue, and SHOULD be disabled if it is FQ.

4. Although l4s-arch claims that l4s-id satisfies the RFC 4774
requirements, it's hard to tell whether it does so.  Specifically:

4.a. From section 7 of RFC 4774:
   Specifications of alternate ECN semantics must clearly state how they
   address the issues raised in this document, particularly the issues
   discussed in Section 2.

I don't see how issues 2 and 3 from section 2 are covered in l4s-id.
From section 4 of RFC 4774:
   (2) How does the possible presence of old routers affect the
       performance of the alternate-ECN connections?

   (3) How does the possible presence of old routers affect the
       coexistence of the alternate-ECN traffic with competing traffic
       on the path?

   When alternate semantics are defined for the ECN field, it is
   necessary to ensure that there are no problems caused by old routers
   along the path that don't understand the alternate ECN semantics.

4.b. Section 4 goes on to describe 3 options for how alternate ECN
semantics should be treated.  I don't see a claim in the L4S docs
specifying which of the 3 options the L4S spec for alternate ECN semantics
matches, but it implicitly appears to be trying to say it's option 3
(unsafe) and asserting that the detection and adaptive response satisfies
the requirement for isolation on option 3, I think?

Maybe there are sections in l4s-id that intend to cover these points,
and there just needs to be text listing what they are, but I don't think
the link is obvious enough to satisfy the "clearly state" requirement
from RFC 4774.  So it would be very helpful to add a list of references
to sections that are intended to address these RFC 4774 requirements.


Nits:
- the list in section 7.1 has a weird formatting problem for the sub-
  list:

   o  Did use of L4S over the Internet result in improvements to the
      following metrics:

   o

      *  queue delay (mean and 99th percentile) under various loads;

----

draft-ietf-tsvwg-l4s-arch-10:
Summary: Almost ready

+1 to Gorry's comments here, especially regarding the use of "all traffic":
https://mailarchive.ietf.org/arch/msg/tsvwg/vMMsQpXs65lk1E7NpV5RlmpyqdI/

Minor:
1. l4s-arch section 1:
   It has been demonstrated that, once access network bit rates reach
   levels now common in the developed world, increasing capacity offers
   diminishing returns if latency (delay) is not addressed.
- This needs a reference.

Editorial:
1. l4s-arch 4.2 section a:
- This is a confusing wall of text.  I think it would be better to
  give a much briefer summary here with a reference.  Exposition
  like "the obvious part" and "the less obvious part" are a minus
  here--I don't think the obviousness claims made here generalize
  well.

2. All the uses of underlining for emphasis are a minus.  The
  places where it seems necessary or useful are a good hint that
  the text on its own is not adequately capturing the intended
  meaning.
  Leaning on this kind of toned emphasis makes assumptions about
  connotations that don't hold very well even for native English
  speakers and break down entirely for non-native speakers, so they
  are generally out of place in a technical document that will need
  to be correctly interpreted by an international audience with many
  non-native speakers, IMO.

----

I'm going to be too pressed for time to do a more detailed review,
but I wanted to get the above comments in.

As a final aside, I'd like to see this happen.  The only goal I'm
pursuing at this point wrt this work is avoiding preventable harm
from pushing this out in a way that's likely to cause confusion
when and if problems are encountered in production.  (In particular,
I have given up on efforts to improve the signaling design, since
the authors have rejected all such suggestions and this work needs
to get moved out of the wg one way or another.)

Best,
Jake


On 07-29, 9:18 AM, "Wesley Eddy" <[e-mail]> wrote:

This message is starting a combined working group last call on 3 of the 
L4S drafts:

- Architecture: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/ 

- DualQ: 
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ 

- ECN ID: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ 

The WGLC will last through 4 weeks from today, and then we'll see what 
to do next.  Please submit any comments you have on these to the TSVWG 
list in that timeframe.

The chairs are considering a possible virtual interim following the 
close in order to work through feedback received.

The work on the L4S operational guidance draft is continuing in 
parallel, but that draft is not being last called yet.