Re: [tsvwg] L4S operational guidance draft

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

Hi tsvwg,

Thanks Greg for writing this doc.  I think it's a good step
forward and headed in the right direction.

My main interest at this stage is making sure that L4S won't
break the rollout for regular/classic ECN.

To that end, in light of the support I saw from several in
the WG for moving the L4S experiment forward, what I'd like
to see landed before docs start going to last call is a
normative requirement on L4S senders to avoid sending L4S
traffic with ECT(1) set unless they have good evidence that
there are not classic marking bottlenecks on-path.

I think this doc makes a good start at describing the
justification for that requirement and listing the kinds of
systems and deployment models that can meet that bar of
"good evidence".

And I think it's a good choice to write it up in a separate
doc like this, so that it can be separately updated to
document other kinds of reasonable evidence, or evolving
observations that would have an impact on these
considerations.

So my most significant bit of feedback is +1 for this doc, I
think it moves the discussion in the right direction in a
helpful way.

A couple of refinements I'd like to see, to give a general
sense of how I'd like to see this doc evolve from its
promising start:

- I'm not sure FQ classic ECN should get quite as big a pass
  here as this doc gives it.  The fact that L4S builds a
  standing queue to a classic marking bottleneck's threshold
  is a problem in itself, but also there is some likelihood
  of hash collisions when there are multiple flows, and those
  are problematic for the colliding competing flows the same
  as you get with a shared queue, even though the smaller
  scope of collision limits the damage.

  I'd be ok with outlining these problems, noting they're
  less severe than the shared queue problem, and allowing for
  more flexibility than the harder requirement that's needed
  for avoiding shared marking queues (like being more
  permissive with how recent or compelling the evidence
  should be, since the harm is more constrained).  But I don't
  think classic marking FQ queues should be treated as a non-
  problem.


- I'd like to see either references to good representative
  samples of the published tests that demonstrate the described
  unfairness issues, or failing that some somewhat stronger
  wording that doesn't just abstractly mention 'unfairness' and
  sum up the scope of the issue as "could be a cause of
  concern".

  Something like "The L4S response to CE is not compatible with
  classic ECN marking." seems to me a more appropriate summary
  description of this issue.  But I think just giving a good
  several references that quantitatively demonstrate the scale
  of the problem seems better than quibbling over exactly how
  to describe it.


- I also have a slight concern over this doc being
  informational.

  I'm not sure whether informational docs are ever updated, but
  I don't think I've ever seen it done, and it seems to be a
  possible necessity over the next years to update guidance from
  this doc as we see how the L4S experiment unfolds, or as the
  research recommended in this doc moves forward and perhaps
  solves the classic queue detection problem, or as we learn more
  about the deployment of classic ECN (whether it takes off or
  peters out or continues its incremental growth).

  Is it possible and reasonable to incorporate this as a
  normative part of the experiment and make it experimental,
  instead of just informational?


As the doc gets closer to complete, hopefully I'll be able to
come back to it and give a full review at some point, but I think
these points capture my initial high level reaction to the -01
version of the draft.

Regardless, I would say WG adoption of this doc sounds useful to
me, and that this is on the right track for providing the
resolution we've discussed to my outstanding concerns with the L4S
experiment wrt its interactions with classic queues.

- Jake


On 11/16/20, 10:31 AM, "Wesley Eddy" <[e-mail]> wrote:

In today's meeting, it was mentioned that the L4S operational guidance 
draft is part of the "safety case" for advancing other L4S drafts.  It's 
not as mature as the other docs yet (e.g. there are several"TODO" 
portions), but we want to understand if people think it's going in the 
right direction and will be suitable for this purpose as it's sketched, 
or what else should be added/changed/etc.

This is on the agenda for Wednesday's meeting.

So, if you have bandwidth, please check out the L4S operational guidance 
draft prior to the Wednesday meeting, so that we can get a better sense 
of how to proceed:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-white-tsvwg-l4sops/__;!!GjvTz_vk!Axw2CdE9R-Px4wskXijeNFQOgQA6FLFUIyrRhvM67g7NWS1bs6Fc23ELKOixjuw$