Minutes IETF109: tsvwg
minutes-109-tsvwg-01

TSVWG Meeting (Monday - Session I)
IETF 109 (Online)
November 16, 2020

Agenda
Jabber Scribe: Pete Resnick
Note taker: Andrew McGregor

1. Chairs Update

   RFCs completed/in Queue:
        §RFC 8899 DPLPMTUD (PS) : Document Shepherd: Wes
        draft-ietf-tsvwg-rtcweb-qos (RFC-Ed: AUTH48) Document Shepherd: David

   Drafts beyond WGLC:
        draft-ietf-tsvwg-transport-encrypt (AD Review) Document Shepherd: David
        draft-ietf-tsvwg-natsupp (with shepherd) Document Shepherd: Gorry
        draft-ietf-tsvwg-ecn-encap-guidelines (Revised I-D Needed -WGLC
        Follow-up)
                Document Shepherd: David
        draft-ietf-tsvwg-rfc6040update-shim (Revised I-D Needed -WGLC Follow-up)
                Document Shepherd: David

2. Milestone updates
        L4S drafts: Milestone date to be reviewed by chairs and draft authors.

3. Announcements and Heads-Up
   NOTE: Authors of the new drafts below can send ONE slide to be presented by
   chairs

        Generic Transport Functions -
        draft-zzhang-tsvwg-generic-transport-functions. Proposing a general
        notion of fragmentation, may be applicable to work in other WGs, please
        read and comment on list.

        Separation of Data Path - draft-asai-tsvwg-transport-review

        SCE Update - various drafts
        HPCC Update - draft-pan-tsvwg-hpccplus
        PFC - draft-dai-tsvwg-pfc-free-congestion-control

4. SCTP Drafts

4.1 Michael Tuexen: bis update to SCTP Spec.
    draft-ietf-tsvwg-rfc4960-bis

Editorial changes coming, this will remove Appendix A.

WGLC is expected December or January, reviews will go to the list after an
updated draft is posted.

5. Transport Working Group Drafts: Protocols

5.1 Joe Touch (proxy/remote): UDP Options
    draft-ietf-tsvwg-udp-options

Work is still in progress, a new revision expected after meeting to reflect
comments around IETF-108. Once this is posted, please review the ID on the list.

5.2 Gorry Fairhurst: DPLPMTUD for UDP Options (10 mins) - Adoption request by
authors
    draft-fairhurst-tsvwg-udp-options-dplpmtud-03

WG Adoption requested. This needs more people to read draft, the Chairs will
take discussion of adoption up on mailing list.

-: How does this relate to QUIC?
QUIC would not use UDP options to implement DPLPMTUD - it has its own
specification in the QUIC Transport ID.

5.3 Greg White: Identifying and Handling Non-Queue Building Flows
    draft-ietf-tsvwg-nqb

- Turning NQB+Default into a PHB Group should be a last resort.
- WiFi mapping needs to go to the list.
- Items 3&4 on remaining work slide (slide #3) imply that at the edge
- : Does one DSCP make sense for access networks and a different DSCP in the
core (e.g., backbone networks)?

6. Individual Drafts

6.1 Markus Amend: DCCP Extensions for Multipath Operation
    draft-amend-tsvwg-dccp-udp-header-conversion
    draft-amend-tsvwg-multipath-dccp
    draft-amend-tsvwg-multipath-framework-mpdccp

WG adoption was requested. The WG chairs will consult with AD about appropriate
next steps for these drafts, including overall approach to work in this area.

Wednesday, November 18, 14:30-15:30 Session II

7. Transport Working Group Drafts: ECN

7.1 Agenda Recap & tooling discovery

7.2 Greg White: L4S Operational Guidance
    draft-white-tsvwg-l4sops

Sebastian: I have a comment on slide 3: "reasonable fairness across range of
conditions" is what's under discussion.  We have currently demonstrated a range
of conditions where reasonable fairness is present, but this may not be
sufficiently broad.

David Black: Where are these tests?  In the hosts or a separate test?

Greg: It depends.  Pre-launch tests for some of it, in-band testing also should
be used and is mentioned in some of the L4S drafts.  A non-realtime response
would be more operational management code.  A mix.

Andrew McGregor: What kind of granularity would be used for the tests? Per
host? Per destination prefix? Greg: One scenario, Residential ISP, you might
have a queue on their network so test results could depend on IP address.

- Gorry: any operators or vendors here have a quick comment on the single queue
3168 treatment?

Andrew: Routers exist that can treat ECT1 as NonECT, but not particular common.
 - with Jonathan in chat mentioning it's technically in violation of 3168.

Bob: It is not formally contrary to 3168; this is not changing the codepoint,
it is just being a non-ECN router for that codepoint.

Gorry: RFCs have specified different treatments based on ECN, e.g. PCN also
specified a different use of ECT(1) (RFC 6660).

Jake: I though RFC 8311, did that and placed some requirements on the behavior.
Isn't that why it was standards track?

Greg: It opened the door to experimental treatment documented in an
experimental RFC.

David: RFC 3168 permits drop instead of marking, so configuring that is
compatible.

Jonathan: This draft is requiring networks to be specially prepared for L4S
traffic, right?

Greg: This is overstating it. These RFC 3168 single queue implementations are
known to exist. Deployment prevalence not known. The impact of them existing is
not catastrophic. The point is to make networks in general prepared for L4s.

Jonathan: Long-running flows sharing a queue can suffer ... also what about
tunnels encountering an AQM?

Greg: Yes, as mentioned on the slides there is an asterisk there as known point
to make with this draft.

Jonathan: Risk analysis needs to consider both prevalence and severity.

Greg: I agree.

Stuart: Apple enabled ECN several years back.  I wish we had the problem today
of deployed legacy routers doing smart queueing instead of tail drop, but
iphone data shows 0 deployment of RFC 3168 marked packets, to many decimal
points.

Jana: +1 to adopting this.

Jake: See our presentation at interim MAPRG meeting. We saw several ASNs that
had non-zero CE marking. This had different vantage points than iPhone data,
but zero percent is not what we saw.
https://www.youtube.com/watch?v=1326B7YYwLM&t=1h12m19s
    https://www.ietf.org/proceedings/interim-2020-maprg-01/slides/slides-interim-2020-maprg-01-sessa-latency-aqm-observations-on-the-internet-01.pdf

Stuart: If you have newer data (ours if from a year or two ago). When we first
collected we saw some plausible CE marking (Argentina? France?) which turned
out to be bogus -- wasn't actual working smart queueing. If there's measurement
of actual working ECN then that would be important to know the prevalence.

Jake: We noted that. There were other networks. By country, it is hard to see
patterns (?)... on a network basis we do see plausible marking.

Bob: Was that single queue, or FQ? fq-codel sees some deployment in recent
years. We need better tests to distinguish this.

Wes: The chairs plan to start an adoption call for the next revision, please
discuss this on the mailing list.

The chairs asked how many had read this draft:

15 read it, 19 has not of 88 participants (at the time of the poll)

7.3 Bob Briscoe: L4S ECN drafts (30 mins)
    draft-ietf-tsvwg-ecn-l4s-id
    draft-ietf-tsvwg-l4s-arch
    draft-ietf-tsvwg-aqm-dualq-coupled

Jana: What is the intent here, are you asking for last call?  The biggest issue
seems to be #16 (classic competition), correct? Bob: Yes, that and whether a CC
is up to speed with the aspirations in this draft? Jana: At a high level, this
seems ready for an experiment. We need to outline what we measure and what we
expect to see as part of the experiment. Jana: If the concern about competition
with classic ECN is an issue, it is only an issue of L4S is successful. I would
like it to become an issue and for L4S to be successful, but needs to be
deployed to make that. Colin, Richard, Mirja, Ingemar, Philip, Mark, Koen: +1
(in chat) David: The path to address the safety concerns runs thru the
operational considerations draft. Gorry: When this is adopted, is the WG ready
to start a WGLC? Do we need something specific? David: I am not sure.  We now
need to judge as a WG whether there is a reasonable approach to dealing with
RFC 3168 "old" equipment. Sebastian in chat: I do not think L4S is ready.
Jonathan in chat: I also do not think L4S is ready. Jake: I do not see why an
RFC is needed to perform an experiment and report observations, many lab things
have been done already, and they demonstrate problems. Colin: I do not think we
need to wait for the ops draft. Lars: I am struggling to understand what the
experiment is.  The draft seems to describe a spec, but not an experiment that
tells whether it succeeded or not? Mirja: The problems that were detected in a
lab make assumptions about deployment.  By deploying it at scale we can find
out whether these are really problems at scale or not. Lars: So, the experiment
is to throw it on the network and see what happens? Koen: The intent is to get
this nailed down, so that CC development engagement can proceed.  We should not
wait, we should start this, so that more people will work on it. Jana: I think
Lars's question is about what is the experiment? History has shown just getting
this ECN marking deployed is a pretty big experiment.  But, yes, encouraging
endpoints to experiment with congestion controllers. Jana: Do we think that by
keeping it as a draft in the WG we gain anything? Sebastian: The operational
safety seems unproven.  Deploying it is un-cautious.  I think we should not be
talking about last call.  We do not have data for a wide range of topologies:
we are discussing in the abstract when many people have not examined the data.
Greg: The specification of classic ECN is 20 years old, with near 0 deployment.
I think we need to move it forward. Lars: Asking for a fabric upgrade is a tall
ask.  If it can't be used by apps it won't ever be used.  The IETF has done
some changes, both in the network and in the endpoints. ECN requires both.  We
need heavier thinking about the incentives and how this will manifest itself in
applications. Koen: In the past we saw specs, but no network interest.  Now we
have the opposite, network interest with good engagement and plans to deploy
it.  This means we can do the experiments now, let's move this forward. Bob:
The network will not deploy it without an RFC out there.

Gorry: How many would review and comment on a last call if we start one before
next IETF meeting? 18 hands raised, 2 not raised, 52 participants at time of
poll.

Jonathan Morton (chat): I think WGLC at least has to wait for l4s-ops to be
completed. Mirja Kühlewind (chat): I disagree, let's get things moving.
Sebastian Moeller (chat): DualQ does not equitably share between the two
classes in a number of relevant cases and requires the protocol to work as
expected. Koen Schepper (chat): +1 to starting a WGLC: Only the real experiment
can bring more engagement and experience. Greg White (chat): +1 to starting
WGLC and to starting the experiment. Ingemar Johansson: The opts draft is not
required before a WGLC of the L4S, on the contrary, I would see that the ops
draft will in part be a result of the experiments. Carsten Bormann (chat): The
purpose of an experimental RFC is to agree what exactly the experiment is.
Sebastian Moeller (chat): Making the endpoints responsible for safety and
equitable sharing is an odd choice, since the same endpoints will profit from
unequal sharing. Andrew McGregor (chat): The ops draft is required... but it
shouldn't be last called until after the experiment is done, because it will
become the ops document for the eventual standard. Jonathan Morton (chat):
There is also a risk that deploying the experiment will "eat" the ECT(1)
codepoint and prevent it from being used in a different way later. Gorry
Fairhurst (chat):  I think Jonathan is correct, the intention is that TSVWG
will assign ECT(1) for this, until the experiment is discontinued. Mirja
Kühlewind (chat): We discussed the question if RFC 3168 marking is being
deployed. If the question is no, L4S deployment is much simpler. If those who
have deployed RFC3168 are the first once to update to L4S that fine as well, if
the answer is no Colin Perkins (chat): I don't see how that data can be found
without trial deployments. (+1 from Jana Iyengar, Ingemar Johansson, David
Schinazi, Mirja Kühlewindd, Ram Ranganathann) (for more details see Jabber log).

The chairs asked who would review these Specs if the WG were to start a WGLC?
18 would review (+1 via chat), 2 would not (out of 52)

All Other Business
8.1 Davide Brunello’s thesis work relevant to L4S (No time this meeting)