[tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

[Gorry Fairhurst <[e-mail]>]

Some people have asked me about various aspects of this debate, and 
towards the end of this process, I’d like to share (as an individual) 
some of my thoughts. Whatever the outcome, I think we have developed a 
lot of material to help us move forward as a group.

We do have a shortage of bits (not uncommon in the IETF), and there are 
many parts to this story:

1. A signal to the network to steer traffic towards or away from the new 
marking: Flow queues avoid needing the endpoint reaction to be known by 
the AQM, and allow each flow have a separate treatment, but have to 
consider the awkward  question of aggregates of flows, and applications 
that choose to shard over multiple flows.

2.  Signal to the network to support network operations, especially for 
wide-scale experiment: It would be good for an operator to know a flow 
is expected to be treated different in their network segment or those 
network segments that follow, and whether they for operational reasons 
wish to avoid that different treatment within their network (e.g., 
following a discovered configuration issue). L4S makes the two transport 
behaviours explicit. I expect some thought would be needed about how 
ECT(1). I think SCE makes it hard to explicitly exclude a flow from 
being a part of an experiment, so we need to be sure that any remarking 
is always benign or helpful. My own view is that using other classifiers 
such as flow IDs or DSCPs brings a lot of complexity to operations, 
because these are used for other purposes in various use-cases, so I am 
not yet clear that helps. L4S introduced an explicit signal (albeit 
on-trust) that the transport will gracefully react to CE marks in an 
appropriate way. I think L4S makes the two transport behaviours explicit 
to observers on the path, I liked that.

3. I don’t know the full set of uses for single queue AQMs that do ECN 
marking:  I would anticipate issues with any AQM that does not conform 
to current transport expectations - just as I anticipate issues with 
routers that configure old-style RED-based ECN marking using large 
thresholds and measuring over deep queues. Guidance will be needed.

4. ECN transport receiver reaction: It would help to have a way to 
reliably tell the receiving endpoint(s) whether the marks they see 
conform to their transport expectations - i.e. whether a packet was 
marked in the new way. SCE nicely makes the marking behaviour explicit, 
I like SCE from this respective.

5. We need to engineer transport methods that work: This is tsvwg’s main 
focus - I would expect to be able to update behaviour as we move forward 
with any work.  As an individual commentator, I expect significant work 
will finally be needed to arrive there (DCTCP was not designed for the 
Internet), but that I suggest we need to decide now on the path to take.

6. We must be able to deploy, manage, and measure the methods for paths 
involving tunnels and encapsulations: This is hard, encaps/tunnels are 
widespread, and tsvwg has devoted significant energy with INTAREA to 
update IETF specs in this area.This was one of the biggest activities 
that faced the proponents of deploying new ECN work, holding up the WG 
while this was done. Designing to work well with tunnels is crucial.

7. We still need to define BCPs that support operation: The use of 
scheduling/queueing fits in this area, but methods depend on the number 
of flows and the way you aggregate - what is applicable in a home CPE or 
WiFi base station is unlikely to be applicable in a service aggregation 
router or an enterprise WiFi deployment. That's why RFC7567 currently 
calls out scheduling, policing and protection as useful, but optional 
components. As an individual commentator, I can see some scenarios which 
benefit from policers, scheduling and/or protection mechanisms, and 
these may well become the accepted best practice for using ECN - and 
hope transports will evolve to mitigate issues, but I would expect 
details to remain scenario dependent.

Alas, I don’t see how we can do all using just the current ECN field, 
and that’s why I say we have a shortage of bits.

My own personal viewpoint is that we need to decide on the benefits for 
enabling ECN in the long term.

Best wishes,

Gorry Fairhurst
(not as a chair)