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

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 15 Nov 2016 19:02:22 +0000

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 +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

     No, you can´t tell people anything
         You've got to show 'em
              Bruce Springsteen
==================================

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 15 Nov 2016 19:09:13 +0000

I think the discussion was off-list, and at the meeting today we said 
we'd now move that to the list. I'll written something that I'll post to 
the list (I need to leave it overnight to re-read so I may havce higher 
confidence it reads correctly).

The first goal is now that we as a WG agree on adoption.

Gorry

On 15/11/2016 19:02, Ingemar Johansson S wrote:
> 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
>
> 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
>
> [email-masked] <mailto:[email-masked]>
>
> www.ericsson.com
>
> You’ve got to show ‘em

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 16 Nov 2016 00:32:45 +0000

Ingemar,

David Black summed up the feeling of the meeting as "all views expressed 
preferred MUST NOT to SHOULD NOT" (now including yours on the list 
here), so he said he would change the doc to MUST NOT at the next rev.

Cheers

Bob

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 16 Nov 2016 15:26:23 +0000

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

---

From: "Bob Briscoe" <[email-masked]>
Date: Thu, 17 Nov 2016 06:40:39 -0000

Gorry,
See inline, tagged '[BB]'

[BB]: The MUST/SHOULD point at issue, was not about what the behaviour
MUST/SHOULD be, it was indeed about whether the behaviour MUST/SHOULD be
IETF controlled.

The -03 text said "protocols and senders SHOULD NOT use ECT(1) unless
specified by an experimental RFC.". However that allows non-IETF protocols
to use ECT(1). We have now agreed it will be 'MUST NOT', which resolves
your concern.

The overall envelope of behaviours allowed for senders using ECT(1) is
covered by the L4S-ID draft (please review). It then says specifics like
how to limit bursts will be covered by the spec of the congestion control
for each transport, e.g. a Scalable TCP, a Scalable QUIC, a Scalable RTP
over UDP etc. The ecn-experimentation draft merely allows us to write the
L4S-ID draft.

That could be true for a future experiment if L4S does not succeed.
However, for L4S, the aim is that there is no need to expose the choice of
ECT(0/1) to the application. ECT(1) will always be better or as good. So a
transport that uses ECT(1) is simply an upgrade under the same socket
interface.

As for the API point above, low latency, low loss with scalable throughput
and without sacrificing utilization is not something an application would
ever choose /not/ to have. If anyone would like to work on an API to give
a choice of a higher latency, potentially underutilized service, please go
ahead :|

> - 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),

[BB]: Again, the IETF "ECT Differences" proposal on the table already
specifies forwarding of CE. Are you saying it doesn't do it well enough,
or just making abstract general points?

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.

[BB]: This draft merely streamlines the process exceptions needed for 3
EXP RFCs that happen to have appeared at the same time. It does not
preclude more in future.

If the IESG approve one of the experiments for exclusive use of ECT(1),
that will preclude other experiments with ECT(1) unless and until the
IESG-approved experiment fails.

See above - the MUST instead of SHOULD addresses this.

Cheers

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 17 Nov 2016 09:40:22 +0000

See below, tagged as [GF}.

> to use ECT(1). We have now agreed it will be 'MUST NOT', which resolves
[GF} I was not physically at the IETF meeting, so I just would like to 
take a discussion of that to the list. (Bob, I saw your position, and I 
saw this suggestion to use the language "MUST NOT", which is why I 
stated that I did not agree with that specific language to preclude 
options, rather I wanted to require something, see the end of this email).
> over UDP etc. The ecn-experimentation draft merely allows us to write the
[GF} I know this for L4S, thanks for your work here, Bob/Koen. I was 
however wanting to be sure that *any difference* experiment needs to 
specify an appropriate CC method.

> transport that uses ECT(1) is simply an upgrade under the same socket
{GF} I wanted to mention the "API" early in the discussion, in the hope 
that some people may also like to think about this. Unless someone says 
more, I'd be happy to not discuss this in this ID.
> a choice of a higher latency, potentially underutilized service, please go
[GF] That may depend on the constraints placed by the CC on the App. 
Again, I simply try to let others in the WG think about this as we go 
forward (we should check our assumptions as this work progresses e.g., A 
strawman would be a particualr multimedia app could prefer reporting 
receiver conditions much less frequently as a trade-off ...). Unless 
someone says more, I'd be happy to not discuss this in this ID.
> or just making abstract general points?
[GF} I saw that L4S has made a proposal on how to do this. My question 
was whether any "Differences" proposal would have to also consider how 
CE was forwarded. I think so, and that's why I said that was important 
to include.
> EXP RFCs that happen to have appeared at the same time. It does not
[GF} Agree.
> IESG-approved experiment fails.
[GF} If that is what the WG asks for, and the IESG approves this, then 
that would indeed be the result!
> See above - the MUST instead of SHOULD addresses this.
[GF] Aha - we still disagree on the words.  I wanted to clarify that I 
did not like the "MUST NOT" text formulation, but to explain that I 
still wanted the requirement to use IETF specifications - I thought we 
have been talking past one another on this. My specific proposal for 
David's draft was that we require use of an IETF-approved sender 
response to CE-marking for all proposed experiments. Are you opposed to 
that?
> “SCTP” and it could be used by UDP-based methods, as these become
{GF] The above is also important to be mentioned - endpoint CC is *NOT* 
just the concern of TCP (that's probably a typo).
> be ready to progress to an adoption call.
[GF]  I'm not so sure that Bob and I have remaining important 
differences - although it seems we didn't converge.

[GF - now with chair hat on... The above comments are on the Individual 
draft, because I'd like to know if any others see points to consider, 
and see if there are any other things we need to work upon. As David 
says, the IETF process would be that the WG takes the final decision on 
all text as we move towards a WGLC. Solid text in the individual 
proposal would certainly help us to progress this quickly thorough the 
IETF:-).

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Nov 2016 12:23:25 +0000

Gorry,

Sorry for delay - my laptop charging lead failed in Seoul last Wed eve - 
I'm just catching up...

On 17/11/16 09:40, Gorry Fairhurst wrote:
> take a discussion of that to the list. (Bob, I saw your position, and 
> I saw this suggestion to use the language "MUST NOT", which is why I 
The IETF already has plenty of RFCs that require this already, e.g. 
[RFC5033] [RFC4774].

I didn't think that ecn-experimentation was intending to remove 
constraints from RFC3168 for any other experiments than the 3 it refers 
to. However, perhaps David thinks differently. Perhaps he chose the 
language "Three areas of ECN experimentation" so that other similar 
experiments could be covered.

If that was intentional, I don't think it was wise. ecn-experimentation 
is merely an admin-saving RFC - to save the IESG having to deal with 3 
EXP drafts and corresponding 3 PS drafts, which would otherwise have to 
accompany them to change RFC3168. It doesn't preclude a 4th experiment 
writing a sister PS draft to ask for yet more changes to RFC3168. So I 
would change the language:

s/Three areas of ECN experimentation/
   /Three experimental drafts/
(This phrase appears more than once.)

This is why I suggested that the "Alternative Backoff" bullet in section 
2 should only refer to the alternative backoff draft, not also L4S-ID. 
Otherwise it implies anyone can pick and choose the alternative backoff 
part of L4S, without the alternative marking part. Either one of the two 
would be harmful without the other.

> {GF} I wanted to mention the "API" early in the discussion, in the 
> hope that some people may also like to think about this. Unless 
> forward (we should check our assumptions as this work progresses e.g., 
> A strawman would be a particualr multimedia app could prefer reporting 
See above, it being safer to rule any other differences proposal out of 
scope of this draft.
> response to CE-marking for all proposed experiments. Are you opposed 
> to that?
No, I'm very much for that.
It would help if you would actually quote the wording you don't like and 
the wording you would prefer.
The proposed wording was in David's slides, but they don't seem to be 
linked from the meeting materials site.

> {GF] The above is also important to be mentioned - endpoint CC is 
> *NOT* just the concern of TCP (that's probably a typo).
> [GF - now with chair hat on... The above comments are on the 
> Individual draft, because I'd like to know if any others see points to 
> consider, and see if there are any other things we need to work upon. 
> As David says, the IETF process would be that the WG takes the final 
> decision on all text as we move towards a WGLC. Solid text in the 
> individual proposal would certainly help us to progress this quickly 
> thorough the IETF:-).
Thanks

Bob

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 23 Nov 2016 16:22:17 +0100

Hi all,

as an individual contributor on this one point:

> Am 23.11.2016 um 13:23 schrieb Bob Briscoe <[email-masked]>:
> 
> I didn't think that ecn-experimentation was intending to remove constraints from RFC3168 for any other experiments than the 3 it refers to. However, perhaps David thinks differently. Perhaps he chose the language "Three areas of ECN experimentation" so that other similar experiments could be covered.
> 
> If that was intentional, I don't think it was wise. ecn-experimentation is merely an admin-saving RFC - to save the IESG having to deal with 3 EXP drafts and corresponding 3 PS drafts, which would otherwise have to accompany them to change RFC3168. It doesn't preclude a 4th experiment writing a sister PS draft to ask for yet more changes to RFC3168. So I would change the language:
> 
> This is why I suggested that the "Alternative Backoff" bullet in section 2 should only refer to the alternative backoff draft, not also L4S-ID. Otherwise it implies anyone can pick and choose the alternative backoff part of L4S, without the alternative marking part. Either one of the two would be harmful without the other.

I would actually rather see this doc as an update to RFC3168 to remove constraints that we simply believe to be wrong (or over-overconstraint). Yes, the experiments we want to do are a good reason to do the updates and talking a little bit about the experiments helps to understand that these changes/updates to RFC3168 are correct. However, I would say we update RFC3168 simply because it’s the correct thing to do. Given this, I would rather like to remove most of the language that talks about these ‚areas of experimentation‘ because I don’t think this constraint is needed. We update RFC3168; all experiments that are possible with these updates are okay. Experiments that are not possible with these updates, need to update RFC3168 separately, or are just not possible if the community does not agree to an other updates.

Be more explicit: I think a sentence like this

"The scope of this memo is limited to these three areas of experimentation.“

doesn't give us anything, because the updates to RFC3168 are anyway valid for all other potential future experiments as well.

Mirja

---

From: "Black, David" <[email-masked]>
Date: Wed, 23 Nov 2016 16:01:56 +0000

> > I didn't think that ecn-experimentation was intending to remove constraints
> from RFC3168 for any other experiments than the 3 it refers to. However,
> perhaps David thinks differently. Perhaps he chose the language "Three areas of
> ECN experimentation" so that other similar experiments could be covered.

That was deliberate.  My views match Mirja's:

> I would actually rather see this doc as an update to RFC3168 to remove
> constraints that we simply believe to be wrong (or over-overconstraint).

The actual experiments remain under IETF control, as IESG approval is required
to publish an Experimental RFC in order to take advantage of the loosened
constraints.

The ECN experimentation draft imposes requirements on these Experimental
RFCs; an important example is that this concern:

> > This is why I suggested that the "Alternative Backoff" bullet in section 2 should
> only refer to the alternative backoff draft, not also L4S-ID. Otherwise it implies
> anyone can pick and choose the alternative backoff part of L4S, without the
> alternative marking part. Either one of the two would be harmful without the
> other.

is already covered by Section 4.4 of the draft, "Effective Congestion Control is
Required" 

Thanks, --David

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]]
> Sent: Wednesday, November 23, 2016 10:22 AM
> To: Bob Briscoe
> Cc: [email-masked]; Ingemar Johansson S; Black, David; De Schepper, Koen
> (Nokia - BE); [email-masked]
> Subject: Re: [tsvwg] ECN experimentation RFC3168 ECT(1) SHOULD vs MUST
> 
> Hi all,
> 
> > I didn't think that ecn-experimentation was intending to remove constraints
> from RFC3168 for any other experiments than the 3 it refers to. However,
> perhaps David thinks differently. Perhaps he chose the language "Three areas of
> ECN experimentation" so that other similar experiments could be covered.
> >
> > If that was intentional, I don't think it was wise. ecn-experimentation is merely
> an admin-saving RFC - to save the IESG having to deal with 3 EXP drafts and
> corresponding 3 PS drafts, which would otherwise have to accompany them to
> change RFC3168. It doesn't preclude a 4th experiment writing a sister PS draft to
> ask for yet more changes to RFC3168. So I would change the language:
> >
> > This is why I suggested that the "Alternative Backoff" bullet in section 2 should
> only refer to the alternative backoff draft, not also L4S-ID. Otherwise it implies
> anyone can pick and choose the alternative backoff part of L4S, without the
> alternative marking part. Either one of the two would be harmful without the
> other.
> 
> I would actually rather see this doc as an update to RFC3168 to remove
> constraints that we simply believe to be wrong (or over-overconstraint). Yes, the
> experiments we want to do are a good reason to do the updates and talking a
> little bit about the experiments helps to understand that these changes/updates
> to RFC3168 are correct. However, I would say we update RFC3168 simply because
> it’s the correct thing to do. Given this, I would rather like to remove most of the
> language that talks about these ‚areas of experimentation‘ because I don’t think
> this constraint is needed. We update RFC3168; all experiments that are possible
> with these updates are okay. Experiments that are not possible with these
> updates, need to update RFC3168 separately, or are just not possible if the
> community does not agree to an other updates.
> 
> doesn't give us anything, because the updates to RFC3168 are anyway valid for all
> other potential future experiments as well.
> 
> Mirja
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 23 Nov 2016 17:46:08 +0000

As promised, at the Seoul meeting, I have now started the call for 
adoption. That does NOT mean this discussion has now ended, nor does it 
mean the discussion isn't important. This discussion needs to happen.

My intention was at this time to understand whether the TSVWG is ready 
to proceed with developing a PS Update to RFC3168.  Please use the list 
to say if you think this work should be done in this WG, or to voice 
concerns on whether to proceed.

Gorry Fairhurst
(as TSVWG Co-Chair).