Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

[Bob Briscoe <[e-mail]>]

Martin,

Mike Heard has just referred to your email below, which I missed at the 
time - apologies. Let me respond now [BB]...

On 26/03/2021 17:15, Martin Duke wrote:
> Speaking as an individual,
>
> Bob has identified all of the problems with using DSCP for L4S. Among 
> them is running L4S through a tunnel.
>
> Another axis of discussion was changing the L4S signal to be 
> ECT(1)->ECT(0) and preserving the CE signal (thread: [1]), which 
> comprehensively solves the coexistence issues. But this fell down, 
> partially because of the (needless) RFC6040 tunnel decap behavior, 
> which will revert any outer-header changes. There are some other 
> problems, of course, they don't affect bystanders and I don't see them 
> as likely to be fatal.
>
> Honestly, if we're going to break L4S in tunnels anyway, I would just 
> as soon break it with the semantic change and not take all the other 
> DSCP baggage that Bob describes. We could even bis the mistake in 6040 
> so that "eventually" the needless behavior goes away.

[BB] The RFC6040 tunnel behaviour shouldn't be thought of as needless. 
The valid ECN transitions are the primary security property of the ECN 
protocol at the IP layer. If it is valid for a middlebox to undo a 
previous increase in severity, it becomes hard if not impossible {1} to 
add enforcement around the system, if found to be necessary later.

I say 'valid', rather than 'possible', advisedly. It's always possible, 
but if it's not valid, it can be detected as an attack, so enforcement 
mechanisms  can be retrofitted. For instance, the Congestion Exposure 
(ConEx {2}) policing and audit enforcement mechanism [RFC7713] relies on 
only upward severity transitions being valid. That's inherent for loss 
(you can't unlose a packet). And it's true for ECN CE. But if both 0>1 
and 1<0 were valid for ECN, I'm certain it would make it hard if not 
impossible {1} to enforce anything about these intermediate transitions, 
if it became necessary in the future.

When we had to choose which would have the higher severity between ECT0 
and ECT1 for RFC6040, I remember going round the relevant intarea and 
secarea groups giving brief heads-ups over a few IETF cycles emphasizing 
that this was a fork in the road - paraphrasing "It's a change to IP v4 
& v6 and if anyone can see any reason why it should be the other way 
round, speak now or forever hold your peace".

Whatever, as I've said before, relying on any change to the ECN 
behaviour of tunnels is a deployment challenge orders of magnitude 
greater than ECN or L4S is (and they are already 3-party deployments). 
The number of types of tunnel, the number of vendors of each, the 
tendency of some to be implemented in hardware, and their typical 
lifespan create a far greater combinatorial problem for deployment. But 
the main problem is that their developers are not in the companies and 
departments of companies that would monetize any of the improvements 
that L4S would bring. It would just be cost for them.

{1} I don't often say impossible, but given I spent 12 years of my life 
'finding' ConEx, if we broke the 'monotonic transitions' property of 
ECN, it would be highly unlikely we could find an alternative if we ever 
needed it.

{2) ConEx might not be known by the current generation of those 
interested in ECN. Very simply:
* If you monitor ECN passing any point in any network you see upstream 
congestion (from senders to here).
* Once you add ConEx, then monitor ConEx and ECN passing the same point, 
you see downstream congestion (from here to receivers) as well.
This allows networks to add efficient congestion policers at the ingress 
to their networks (whether edge or border) for the single aggregate of 
traffic passing any point. Obviously IP is unidirectional, so it's much

{3} I appreciate this is vague, but I'm trying to get ready for 
presentations this afternoon at the same time.


Bob

>
> This is not a statement in favor of 1->0 marking. It is a statement 
> that if the WG is going to insist on a DSCP to ship this design, I 
> would prefer 1->0 over that.
>
> Sorry to complicate the discussion.
>
> Martin
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/tsvwg/TDMKRyH9E6zho6VkiXDYes7FZK0/ 
> <https://mailarchive.ietf.org/arch/msg/tsvwg/TDMKRyH9E6zho6VkiXDYes7FZK0/>
>
> On Fri, Mar 26, 2021 at 7:00 AM Jonathan Morton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     > On 26 Mar, 2021, at 2:30 pm, De Schepper, Koen (Nokia -
>     BE/Antwerp) <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     > I understood the goal of your proposal. But before diving into
>     the details of a DiffServ-based proposals, I'm taking a step back
>     asking: Is using DiffServ an option at all. I don't believe so
>     (see other reply to Steve's mail related to the reason for
>     deployment).
>     >
>     > As a second step after this, "IF" using DiffServ is an option,
>     then L4S and SCE can get married and we can benefit from both.
>
>     In recent days I have put forward two distinct ways to use
>     Diffserv in this context, both of which I believe are workable. 
>     The one I prefer is of course the one involving SCE-type
>     signalling rather than L4S-type signalling; it consumes fewer
>     DSCPs and has fewer failure modes.
>
>     In the SCE context, Diffserv is useful for three things:
>
>     1: Protection of early experimental deployments.  This is temporary.
>
>     2: Enabling dual-queue AQMs to perform SCE classification and
>     signalling.
>
>     3: Allowing SCE AQMs to distinguish SCE and non-SCE traffic
>     embedded in the same tunnel.
>
>     SCE itself is compatible with existing dumb FIFOs, policers,
>     dropping AQMs, and RFC-3168 AQMs both single and multi-queued,
>     without the assistance or need for any Diffserv mechanism. Most
>     SCE AQMs will probably have AF or FQ functionality to ensure good
>     compatibility with conventional traffic.
>
>     Diffserv is strictly an enhancement to SCE, which can be deployed
>     in those contexts which benefit from it.  The CDN -> ISP ->
>     subscriber path is an ideal context for deploying a coherent
>     Diffserv system.  I think that dovetails very nicely with the
>     technical needs of DOCSIS Low Latency.
>
>      - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/