[tsvwg] ECT(1): Plan for Vancouver

["Black, David" <[e-mail]>]

During the interim meeting (https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/session/tsvwg) the plan for dealing with ECT(1) in Vancouver was discussed based on version -02 of the chairs slides that are posted here: https://datatracker.ietf.org/doc/slides-interim-2020-tsvwg-01-sessa-ect1-chairs-slides/ .  The chairs believe that the rough consensus of the TSVWG WG is to proceed as outlined on slides 5-7 of that slide deck, whose contents are reproduced below.  Anyone who disagrees with this course of action should reply to the list with an explanation.

-- Slide 5: ECT(1): Agreeing on the Decision to be Made


*         Next two slides: TSVWG Chairs attempt to state the decision

  *   Goal of this Interim Meeting: Rough consensus on decision to be made
  *   Non‐goal of this Interim Meeting: Actually make the decision


*         Vancouver meeting plan (in order):

  1.  Begin with revised versions of next two slides
  2.  L4S and SCE each present a few slides on best use of ECT(1) for the Internet
  3.  TSVWG Chairs set time & content guidelines, review and post in advance (1 week or more)
     *   TSVWG Chairs frame and moderate Vancouver meeting discussion
  4.  A small miracle happens, and the decision is made (we hope)



*         Now: Review next two slides for content

*         Do not attempt to make decision now.

-- Slide 6: DRAFT Vancouver SLIDE 1: Framing the ECT(1) Codepoint Decision

Background: RFC 4774 “Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field”

  *   RFC 4774 assumes DSCP as signal of alternate ECN semantics.
  *   TSVWG situation: Two proposals that use ECT(1) as that signal [L4S, SCE]

Decision: How ECT(1) signals alternate ECN semantics to network:

  1.  Input, e.g., classifier for “queue” selection [L4S]
  2.  Output, e.g., indication of lesser degree of “queue” congestion [SCE]
At Internet scope: Choose at most one, not both.

-- Slide 7: DRAFT Vancouver SLIDE 2: Friendly Coexistence with Competing Traffic

Both proposals [L4S, SCE] employ RFC 4774 Option 3 (section 4.3):

  *   Incremental Deployment Option 3: Friendly Coexistence with Competing Traffic
  *   Competing Traffic uses existing TCP congestion control, e.g., Reno, Cubic, etc.
Coexistence Focus: Shared bottleneck queue with ECN AQM [RFC 3168]

  *   FQ network nodes: Not a significant cause of coexistence problems
Scenario: Traffic competition at shared bottleneck queue:

  1.  Starvation of one class of traffic is not an acceptable outcome.
     *   Starvation may occur in network and/or at endpoints (e.g., caused by congestion response)
  2.  Competing Traffic drives bottleneck queue occupancy level.
Proposals need to explain how to deal with this scenario.

Thanks, --David (on behalf of David, Wes & Gorry - TSVWG chairs)