Subject: [tsvwg] WGLC: draft-ietf-tsvwg-tunnel-congestion-feedback-03

From: "Black, David" <[email-masked]>
Date: Wed, 26 Oct 2016 22:51:41 +0000

This email announces a TSVWG Working Group Last Call (WGLC) on:

                       Tunnel Congestion Feedback
             draft-ietf-tsvwg-tunnel-congestion-feedback-03
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tunnel-congestion-feedback/

Due to the upcoming Seoul meetings, this WGLC will last for about 2.5 weeks
weeks, ending at midnight Korea Time on Sunday, November 13, in order to
enable discussion of any issues at TSVWG sessions in Seoul later that week.

Comments should be sent to the [email-masked] list, although purely
editorial comments may be sent directly to the authors at
[email-masked].  Please cc: the
WG chairs at [email-masked]  if you would like the chairs to track
such editorial comments as part of the WGLC process.

There are two IPR disclosures that relate to this draft:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tsvwg-tunnel-congestion-feedback

I will also kick off WGLC by announcing a proposed resolution of the ECN
codepoint issue for this draft - that issue involves which ECT codepoint(s)
to use for the "faked" ECN in the outer header of a packet whose inner
header does not enable ECN.

With some gentle guidance from the ADs, the proposed resolution is to use
only ECT(0), and state that ECT(1) MUST NOT be used for a couple of reasons:

1) Tunnel Congestion Feedback (TCF) needs only one ECT codepoint, hence
RFC 3168 indicates that ECT(0) SHOULD be used for TCF.  This "SHOULD" is
a general recommendation for all protocols that use only one ECT codepoint.

2) There's an IETF intent to use ECT(1) with L4S, and TCF interacts badly with
L4S to the point of being destructive.   This interaction arises within a TCF tunnel
that uses "faked" ECN, because L4S marks ECT(1) packets as having experienced
congestion (CE mark) with much higher probability than drop-equivalence, but
the TCF tunnel egress treats all CE marks as drop equivalent and drops the
packets.  The resulting sender congestion response (backoff) to the drops
will be far more severe than it should be and avoiding that response is why
ECT(1) MUST NOT be used for TCF.  This "MUST NOT" is specific to TCF due
to the interaction with L4S.

WGLC comments are welcome on this proposed resolution.  I'll work out
actual text with the TCF draft authors with input from interested parties
(e.g., Bob Briscoe), as the above rationale does need to be captured in the
draft.

Thanks, --David
--------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953     Cell: +1 (978) 394-7754
[email-masked]  <=== NEW ===
--------------------------------------------------------