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

[Gorry Fairhurst <[e-mail]>]

See below, tagged as [GF}.

On 17/11/2016 06:40, Bob Briscoe wrote:
> Gorry,
> See inline, tagged '[BB]'
>
> On Wed, November 16, 2016 3:26 pm, Gorry Fairhurst wrote:
>> 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).
>
> [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.
>
[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).
>> - 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.)
>
> 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.
>
[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.

>> - 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.
>
> 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.
{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.
>> - 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.
>
> 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 :|
[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.
>> - 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?
[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.
> 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.
[GF} Agree.
> 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.
>
[GF} If that is what the WG asks for, and the IESG approves this, then 
that would indeed be the result!
>> 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.
> 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?
> Cheers
>
>
> Bob
>
>> 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.
{GF] The above is also important to be mentioned - endpoint CC is *NOT* 
just the concern of TCP (that's probably a typo).
>> 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
[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