Minutes IETF111: tsvwg
minutes-111-tsvwg-01

TSVWG at IETF 111 July 25 - 30 2021

14:30-15:30 Monday Session II ( 1 hour )
Chairs: Gorry Fairhurst, Wes Eddy, David Black
Notetaker: Michael Scharf

1. Agenda

No agenda bashing

2. Chairs Update

RFC’s completed/in Queue:

    RFC 8837 - draft-ietf-tsvwg-rtcweb-qos
    RFC 8899 - DPLPMTUD
    RFC 9065 - draft-ietf-tsvwg-transport-encrypt

With IESG:

    None.

Drafts beyond WGLC:

    draft-ietf-tsvwg-ecn-encap-guidelines (Writeup) Document Shepherd: David
    draft-ietf-tsvwg-rfc6040update-shim (Writeup) Document Shepherd: David
    draft-ietf-tsvwg-natsupp (Revised I-D Needed) Document Shepherd: Gorry

Martin Duke: For SCTP NAT (natsupp draft), the ball is with the authors.

Work related to other WGs:

    draft-ietf-tram-stun-pmtud - see TRAM WG
    APN - see INTAREA BoF
    Further related drafts (see slides)

Milestone updates: See slides for details

Liaison updates:

    Wireless Broadband Alliance (WBA) Liaison Request - (DSCP/5QI mapping)
    Caretaker: David

    3GPP Liaison Request - (SCTP & DTLS)
    Caretaker: Gorry

    GSMA Liaison Request - (Multipath DCCP)
    Caretaker: Gorry

3. Transport WG Drafts: ECN

3.1 Wes: L4S ECN drafts

Wes:
Recap of TSVWG Interim on May 10 with large amount of feedback
Focus:

    Finalizing the transport requirements
    Ensure safe experimentation

No full agreement in interim meeting, but strong consensus that the OPS draft
was a basis for defining the experiment.

Bob: I still have pending edits. Unfortunately, there are some XML editing
issues that prevented an update to resolve the issue relating to IPsec.

David: presented a list of some of the topics brought up on the list (slides
created with Jonathan and others). Issues (1): L4S-Internet Coexistence

    Documents potential issues

Issues (2): Dual Queues and AQM

    Documents potential issues

Slides have been posted (3.1-A on materials page)

David’s slides on issues seen.
Bob: Are these presented as a chair or as a proxy?
David: A mix of both, but not an authoritative statements.
David: This is just a little glimpse of the adventure that is coming during
WGLC of the main L4S drafts. 3.2 Bob: L4S ECN drafts

Drafts: draft-ietf-tsvwg-ecn-l4s-id, draft-ietf-tsvwg-l4s-arch,
draft-ietf-tsvwg-aqm-dualq-coupled

Recent L4S progress: Recent activities and implementation improvements.

Update to draft-ietf-tsvwg-l4s-arch to address Vidhi’s review.

Update to draft-ietf-tsvwg-ecn-l4s-id e.g. to address VPN anti-replay
protection, some efforts regarding coss-area alignment regarding tunnel
resequencing.

Update to draft-ietf-tsvwg-aqm-dualq-coupled with additional justification of
default parameters.

Q&A postponed after l4sops presentation
(Some side discussion in the chat regarding the scope of David’s earlier
slides, conclusion captured at end of 3.1)

3.3 Greg White: L4S Operational Guidance

Draft: draft-white-tsvwg-l4sops

Review of scope and status: Not seeking WGLC currently on the OPS ID.

Various deltas in -01

Section 6 discusses options for existing RFC3168 networks: Prerred, less
preferred and last resort options

Expectations on experimental deployment in network and applications & OS; there
is no flag day. Martin: Are canary-based methods already described in the
draft? Greg: A little, but not yet mentioned “canary” methods specifically,
should we say more? David: Would be good to write this up. Gorry: This is a
very common technique to run tests with new transport features. I’ll send
something. Wes: Might be compelling. Jonathan: I don’t have any opinion so far
regarding canary-based methods. Also, 10 seconds is too long to be the boundary
between short and long flows. Jonathan: Short flows in combination with IPTV
settop-box results in buffering. Kavin Smith: What does 10sec mean? 10sec in
queue? 10sec playback time? Jonathan: 10sec flow completion time. Greg: Flows
long enough to impact other flows. 10sec is an example in the draft. Bob:
Difficult area. When a new flow enters the system, it gives headroom. Some
number is required. Convergence time also has to be analyzed for L4S flows.
Exact fairness all the time is not a good idea neither.

Bob: The pending update to l4s-id-draft was just posted.

Wes: Watch out for the WGLC announcement for the L4S Core Specs.
David: The purpose of WGLC is to figure out whether the drafts are ready. A
WGLC does not mean that the documents are indeed finished.

Gorry: The next session will be short. Please have a look at what you really
want to discuss!

End of meeting session 1.

Thursday Session I ( 1 hour )

4. Agenda Review

4.1 Michael Tuexen: RFC4960.bis - WGLC

 draft-ietf-tsvwg-rfc4960-bis

DB: Is this (4960bis) going to the next rung on the standards track (full
standard)? GF: Yes, that is the intent for publication of this as an RFC. DB:
Extensions to SCTP are not consistent with that goal, should be taken up in a
separate draft or drafts.

Jonathan Lennox: It would be good for the draft to have a full list of the
changes. Michael: We have an rfc for the majority of the changes JL: Over and
above of 8540 would be good. GF: With those changes I would be happy to start a
working group last call. Please send a revised ID.

5. SCTP WG Drafts

5.1 Magnus Westerlund: RFC6083.bis

draft-westerlund-tsvwg-dtls-over-sctp-bis

Current proposal is based on DTLS 1.3. See slides for the issues that this work
is facing.

DB: Did you say that 3GPP will be satisfied with a DTLS 1.2 solution in their
time frame and they would be willing wait for us to figure out 1.3? MW: Yes,
they are willing to continue to use DTLS 1.2. That is one possibility, but we
will try to find something better in September that will work for DTLS 1.3. GF:
Will you have a proposal to discuss during a September interim? MW: A late
September draft of a proposal is likely. DB: Martin(AD) would you please make
the Security area is aware of this mismatch between DTLS 1.3 and SCTP? MW: Yes,
we are working on this. 5.2 Michael Tuexen: NAT alternatives for SCTP

draft-ietf-tsvwg-natsupp

GF: We need to think more and discuss on the list. I don’t think we have time
to discuss now. Please take to the list. GF: if the proponents of the other
method could write a draft that would really help with discussion. MT: There is
a write up in a github repo. 6. Transport : Protocols 6.1 Ana Custura: DSCP
Considerations

draft-ietf-tsvwg-dscp-considerations

DB: You probably know that the 802.11 considerations will have to be written up
twice, once for RFC 8325 and once for all the pre-RFC-8325 running code in WiFi
access points (NQB draft is a worked example). GF: Great, we just need two
people to help with the draft. Martin Duke: Is it in scope to write down how
this works and how this is supposed to work? GF: this document is about how
DSCPs should work in the wild, even if that is not how they are used. (To be
precise, there are two versions of 802.11 DSCP-related behaviour, the draft
should consider the implications of both.)

Bob Briscoe: the IETF has published RFCs that say what should happen, this
covers what is happening. Can this be read as the IETF saying that what is
happening is what SHOULD be happening? GF: I am glad this is a work item, this
could actually be a BCP in the future. We need to cover how to use DSCP and
just document how weird the world is. More decisions later on this in tsvwg!

AC: Please help with any advice for what to look for in measurements for the
next version of the draft.

6.2 Greg White: NQB

 draft-ietf-tsvwg-nqb

NQB PHB has changed to use the new proposed Diffserv codepoints (DSCPs 45/5).
An early allocation will be requested from IANA - to be requested and confirmed
on the tsvwg list.

The draft has many changes and is on track for a WGLC soon.

6.3 Joe Touch (proxy): UDP Options

draft-ietf-tsvwg-udp-options

Status update - see slides. Interim meeting likely to resolve outstanding
issues.

7. Other Individual Drafts

7.1 Markus Amend: Multipath DCCP

  draft-amend-tsvwg-multipath-dccp

MP-DCCP - PEOPLE WHO HAVE READ THIS ID, (OR A RECENT VERSION)
RAISE HAND 18
DO NOT RAISE HAND 10
PARTICIPANTS 28

INTEREST IN STARTING A TSVWG WORK ITEM ON MP-DCCP
RAISE HAND 25
DO NOT RAISE HAND 9
PARTICIPANTS 34

GF: David do we want to wait for the IPR process to complete before an adoption
call for this draft? DB: I think we should wait for the IPR process results to
be posted (soon). Markus: How long does this take for adoption? GF: We need to
wait for IPR then we can do the adoption call on the mailing list, calls are
always on on the mailing list. DB: Think you will have the result in September.

Markus Amend: The only connecion I see between MP-DCCP and QUIC is using
datagram and MASQUE, we think that is much more complex and much heavier and it
would take a lot longer to get into 3GPP. We are aiming for the release 18 time
frame.

Martin Duke(AD): We have approached the QUIC WG many times about a multipath
work item and they aren’t interested at this time. There are generic problems
around multipath that are maybe research questions and I am glad we have a
platform with this and SCTP to explore those. Mirja Kuhlewind: For 3GPP release
18 people are in favour of a multipath QUIC solution, but that has been
delayed. I haven’t seen a 3GPP proposal for MP-DCCP. There isn’t a strong 3GPP
requirement right now. Markus Amend: With a tsvwg adoption then MP-DCCP could
be a viable alternative and then we will see.

Meeting closed.