Subject: [tsvwg] ecn-encap-guidelines and rfc6040update-shim updated

From: Bob Briscoe <[email-masked]>
Date: Mon, 12 Nov 2018 14:48:17 +0000

David,

We have revised draft-ietf-tsvwg-ecn-encap-guidelines from -10 to -11.
And draft-ietf-tsvwg-rfc6040update-shim from -06 to -07

They are (again ;) ready for WGLC.

Neither case is just a simple re-spin with no changes. You can look at 
the diffs yourself, but below is the rationale for one main change each:

      ecn-encap-guidelines

The main change was to remove the whole short section that contained the 
following single normative requirement:

    Any congestion
    notification from an algorithm that does not conform to the
    recommendations in [RFC7567] MUST NOT be propagated from a lower
    layer into the ECN field in IP (see also [RFC4774] on alternate uses
    of the ECN field)

...because I realized a) this was too strong, but more importantly b) 
this was not in scope, being the subject of RFC4774. So instead we 
deleted the whole section, explained this in the 'Scope' section, and 
referred from there over to RFC4774.

We had originally added this section when we discovered that the 3GPP 
specifications of "all-or-nothing" ECN for VoLTE is incompatible with 
what Internet congestion controls are designed to expect from an AQM. 
Instead, in the scope section, we have given this as an example of the 
danger of defining alternative ECN semantics for a certain DSCP, if that 
DSCP might get stripped as a packet is decapsulated (this aspect belongs 
in this draft 'cos it is relevant to decap, whereas complying with 
RFC7567 is about ECN semantics, which is RFC4774 territory).

      rfc6040update-shim

the main change was to alter one of the requirements
from:

       even if an implementation of a tunnel ingress does
       not claim to support RFC 6040, RFC 4301 or the full functionality
       mode of RFC 3168:
       *  [it] SHOULD zero the outer ECN field in its default configuration.

to:

... * it SHOULD be able to be configured to zero the outer ECN field

The previous text was, again, straying beyond the scope of this draft. 
The only case that RFC6040 did not already deal with was pre-existing 
implementations. I figured that most pre-existing implementations would 
be able to be configured to set the ECN field to zero in the outer, 
given they can generally set a default DSCP in the outer and most can 
set any of the 8 bits of the former ToS byte.

Bob

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