Re: [tsvwg] ECN experimentation RFC3168 ECT(1) SHOULD vs MUST

[Gorry Fairhurst <[e-mail]>]

Ingemar, et al...

My promised email on draft-black-tsvwg-ecn-experimentation-03 - please 
comment on list (if you wish)

There was a long thread of email off-list, much of which influenced -03, 
but some of which was mentioned at the IETF WG meeting. To help restore 
context to anyone interested - and to allow other people who are not L4S 
authors to comment, I include some points below.

I questioned whether *the PS update* is the correct document to require 
a “MUST” ECT usage. Instead, I would prefer careful use of language that 
requires only IETF protocols to be used (see below).
- endpoints: I wanted to warn that choosing the ECT(1) codepoint could 
result in substantially different network behaviour, and needs to be 
controlled by a congestion control method specified for use with ECT(1). 
(TCP-Prague could be one method that may define such mechanisms in 
future. This also must work with UDP with appropriate CC.)
- API: Changing a Proposed Standard to *allow* separate (different) use 
of ECT(0) and ECT(1) will have implications on application design and 
recommended operational practice.
- Apps: I wanted to be careful that we did not say anything that would 
dissuade applications from a choice of an ECT(0) or ECT(1) style ECN 
response.
- Routers: I think any IETF “ECT Differences” proposal is REQUIRED to 
specify how a router will forward CE-marked packets.
- Although currently reported measurements (that I did with Brian T, et 
al - see PAM etc) don’t expect problems with “ECT Differences”, we 
tested only specific cases and hence do not know all cases, that’s a 
small risk!
- And... alas, what we hope for doesn’t always happen (e.g., CONEX - has 
nice features), so I’d also urge to avoid changes to the PS targeting 
one specific experiment (see tsvarea talk this week). There is still a 
possibility that L4S may not be the last IETF-sanctioned experiment that 
will ever be done with ECT(1). This draft mustn't confine those 
experiments unecessarily.

Specific suggestions:

I’d like to see the “ECT Differences” text is exclusively scoped to say 
that it enables Use of ECT(1) for a different *** IETF-approved sender 
response to CE-marking ***. Currently the text may sound like a spec may 
not need to be IETF-approved, that’s not what I expected.

I noted a NiT, I think the ID should say: “Alternative Backoff”: For 
congestion indicated by ECN, use a different IETF-approved sender 
response to CE-marked packets.” Although ABE defines this for “TCP”, and 
“SCTP” and it could be used by UDP-based methods, as these become 
standardised.

David said he is going to try to address the points raised on his slide, 
and when we have discussed this new version on the list, I expect it to 
be ready to progress to an adoption call.

Gorry


On 15/11/2016 19:02, Ingemar Johansson S wrote:
>
> Hi
>
> Tried to follow the should vs must discussion at the Tuesday TSVWG 
> session.
>
> Given how I feel (not 100% certain that my view is correct) that other 
> standards foras like e.g 3GPP treat IETF-SHOULD then I would actually 
> prefer the MUST, at least
>
> ECT(1) MUST NOT be used unless otherwise specified by an Experimental RFC.
>
> But taking a step back.. What harm would it bring if a MUST is used 
> instead of a SHOULD. Trying to trace through the emails but fail to 
> get a proper understanding. If there is a email that discusses this 
> then a link to that would be appreciated.
>
> Regards
>
> /Ingemar
>
> ==================================
>
> Ingemar Johansson M.Sc.
>
> Master Researcher
>
> Ericsson AB
>
> Wireless Access Networks
>
> Labratoriegränd 11
>
> 971 28, Luleå, Sweden
>
> Phone [phone]
>
> SMS/MMS [phone]
>
> [e-mail] <mailto:[e-mail]>
>
> www.ericsson.com
>
> No, you can´t tell people anything
>
> You’ve got to show ‘em
>
> Bruce Springsteen
> ==================================
>