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

["Bob Briscoe" <[e-mail]>]

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.

> - 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.

> - 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.

> - 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 :|

> - 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.

>
> 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.

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.
>
> 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