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