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.