Re: [tsvwg] L4S operational guidance draft

[Pete Heist <[e-mail]>]

Hi Jake/Wesley, just one add below...

On Tue, 2020-11-17 at 16:07 +0000, Holland, Jake wrote:
> 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.

One addition to this is the fact that when tunneled traffic traverses
fq_codel, since the 5-tuple for all of the tunnel's inner flows is the
same, that places them in one fq_codel queue, leading to the same
safety problem when L4S and non-L4S flows meet. So, while single queue
RFC3168 AQMs or hash collisions are one way for that to happen,
tunneled traffic may be a more likely way. We recently added a test
scenario using Wireguard through fq_codel to cover that case, which for
some reason I didn't think to try earlier:

https://github.com/heistp/l4s-tests/#unsafety-in-tunnels-through-rfc3168-bottlenecks

That should probably be covered in the guidance in relation to FQ
classic ECN as well...

> - 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$
>  
> 
> 
>