**TSVWG IETF 115 session** Monday November 7th, 2022 - 2 hours Room Name: Kensington 1 Notetaker: Esko Dijk **TSVWG Accomplishments and Status** (Chairs present - see slides) **1. Agenda** (Chairs present - see slides) \`\`\`1: WG Status and draft updates - chairs (15 minutes) Rotating Chairs - Welcome Marten RFC's completed/in Queue: draft-ietf-tsvwg-ecn-l4s-id Document Shepherd: Wes draft-ietf-tsvwg-l4s-arch Document Shepherd: Wes draft-ietf-tsvwg-aqm-dualq-coupled Document Shepherd: Wes With IESG: None. Drafts beyond WGLC: draft-ietf-tsvwg-ecn-encap-guidelines (Writeup Needed) Document Shepherd: David draft-ietf-tsvwg-rfc6040update-shim (Writeup Needed) Document Shepherd: David draft-tsvwg-dscp-considerations (post WGLC) Document Shepherd: David Chairs: Milestone updates - see tracker. Chairs: Status updates on other WG drafts: draft-ietf-tsvwg-nqb (WGLC) draft-ietf-tsvwg-usr-exp User Ports for Experiments (Ready for WGLC) 1. Notices and Related Drafts (10 Mins) Liaison notices, if any: WBA Liaison Request - (DSCP/5QI mapping) David 3GPP Liaison Request - (SCTP & DTLS) Gorry GSMA Liaison Request - (Multipath DCCP) Gorry Chairs: Announcements and Heads-Up IEPG Presentation on DSCP Measurement Proposed change to the PHB-ID IANA Registry \`\`\` **Chairs Topics** Obsoleting the PHBID registry at IANA **TSVWG Leadership Update** Marten is welcomed. Martin Duke: thanks David Black for his contributions and expertise, for everything. **2. Individual drafts session** 2.1 draft-livingood-low-latency-deployment (see slide) 2.2 draft-miao-tsv-hpcc Talk descibed HPCC++ deployment, large market acceptance. 2.3 draft-kaippallimalil-tsvwg-media-hdr-wireless This ID proposes a set of metadata for wireless networks carrying low-latency media, and how to transport this metadata. **3. WG Differentiated Services & AQM Drafts** 3.1 Gorry Fairhurst/Ana Custura: DSCP Considerations (10 mins) draft-ietf-tsvwg-dscp-considerations-05 Post WGLC (see slides) One WGLC suggestion not yet included (slide 4/6): text is pending on "Bleaching" and will be in next revision. 3.2 Greg White: L4S Operational Guidance (10 mins) draft-ietf-tsvwg-l4sops * Ths WG is keeping this as a living document to capture experience gained during L4S deployment experiments. * L4S interops schedule shown; ongoing interop events with 5G/WiFi/... implementations. There is also a demo at Hackathon Happy Hour today. Looking for participants for next IETF Hackathon Yokohama. * Completion milestone: July 2023. **4. WG Transport Drafts (DCCP, UDP & Other Transports)** 4.1 MP-DCCP (20 minutes) 4.1.1 Minjun Xi*: Interoperability of MP-DCCP Ported MP-DCCP to Android (kernel). Tests run with iperf. Test environments: LAN, WAN. Next steps to test with real traffic (e.g., Skype). Conclusion: Interoperability was reported, -06 draft mature and complete. (see slides for details) David: It is good to see running code for this, a solid piece of work. Thank you. 4.1.2 Markus Ahmed: MP-DCCP draft-ietf-tsvwg-multipath-dccp Discussion of intended document status Request for reviewers for WGLC Status: We think there are only minor open issues, this is feature-complete now. (many issues from reviews were solved since the past IETF meeting - see slides for detail) Note: Slide 4/5 is missing some checkmark graphics - not complete. * left column table is completed; right column table topics are next up. Summary: There was a successful interop (see above MP-DCCP presentation) and WGLC requested. Also requesting the WG to consider revisiting the EXP status to Proposed Standard track. Gorry: A show of hands requested for who has read this draft or a previous version of it. Poll result: 14 have read (20 have not read). Requesting any input on PS status, why wouldn't it be PS? Anyone thinks it should be EXP? Martin Duke: We are requesting input to help inform this decision about the publication track. It would make sense to align with the intended status for the MP-QUIC work. Initially, multipath scheduling seemed like mostly a research issue not so much for practice. Markus: (...) Martin: This protocol work seems ready to progress, solid. A PS status would communicate to others that it is "safe to use". Lars Eggert: The scheduling problem is still hard. We have solutions that work for specific path combinations, but it remains hard in general. From a safety point of view it should be fine to go ahead. But we do need a more general scheduler for multipath scenarios (for future research). Sri Gundavelli: What is the key technical differences with other solutions? - compare it with mobile / cellular / 5G systems where multipath is supported e.g. 2 different access technologies, or mobility. Markus: We don't follow this (yet). Martin: There can be some concerns on fairness issues. People will adopt MP for its performance. This could mean we might decide not to stamp it as "standards track" yet. Lars: This refers to congestion control work by Damon. A mathematically proven method. Could pick this up as baseline. Need to figure out if we can feel comfortable with this. What do you use currently for congestion control? Martin: MP-DCCP is currently using BBR CC. ... Coupled congestion control. Lars: This draft needs to define in words how to do safe congestion control. Mirja Kuehlewind: There is still a lot of stuff additional to multipath TCP, so this is not a small change. So there's a slightly higher barrier (for PS.) So someone should be able to produce an independent implementation from the draft text (not using the existing code). Gorry: The Chairs and ADs are asking, what is the maturity of this spec? What are the risks? Give your input - go to the AD or chairs - quickly! Question: How many people would review this doc in WGLC? Poll: 8 would review, 10 would not (or think it's not yet ready for that). 4.2 SCTP AUTH 4.2.1 John Mattsson: SCTP Authentication analysis (10 mins) (see slides) Five SCTP-AUTH security issues found (2 reflection, 2 replay, 1 theoretical only). Michael Tuxen: Issue 1 reflection, we missed putting in specific things for this. But for DTLS over SCTP it seems no issue of "inserting data" by attacker. On issue 2: SCTP doesn't provide better replay protection than the underlying protocol, that's clearly stated / understood. We just didn't specify additional things there. On issue 3: we didn't specify something here but didn't know this. On issue 4/5: at the point of time of SCTP-AUTH, there was no difference assumed between attackers who could read packets and who could write packets. David: "replay" is used a bit inaccurately here. These here are much more specific replay attacks where the replay happens exactly at the right time. Can't happen at arbitrary later times which is usually meant with "replay attack". Martin Duke: Thank you for breaking our stuff :-) Good contributions, thanks. 4.2.2 Michael Tuexen: SCTP-Auth 4895.bis (5 mins) draft-tuexen-tsvwg-rfc4895-bis (see slides) Michael: Should we adopt this as a WG document first and then do the substantial changes (updates of RFC 4895 text)? Magnus Westerlund: We need to fix the issues that were brought up, agree. Poll: To get a feel of how much people have looked: Who has read this draft? (1 has, 17 not). Gorry: Few people had the read this draft. The chairs encourage people to read this draft - today there has been a number of talks on security and we will look for adoption by the group at a future time. 4.3 Magnus Westerlund: DTLS over SCTP (10 mins) draft-ietf-tsvwg-dtls-over-sctp-bis (see slides) (Slide 6/11) Requesting WG/people to perform own security analysis - are suggested mitigations sufficient? Michael Tuexen: Is it relevant what Open Source implementations provide, given the IPR issues? Can I use an open source DTLS information to test, or is part patent protected? (asking since WolfSSL was mentioned) Magnus: ... David: I suggest to take this discussion on the list. Not a good topic here. Martin Duke: If you're confident that DTLS 1.3 is good w.r.t. roadmap and implementations, then it's fine to go for 1.3 only. Magnus: It may be good to delay this (1.3) question a bit, see later. Magnus: Slides 10/11 are asking for input. Conclusion: The timeline for completion is delayed. We may need to notify 3GPP of delay with an Liason Statement. 4.4 UDP Options (5 mins) 4.4.1 Joe Touch* (proxy Chairs, TBC): UDP Options draft-ietf-tsvwg-udp-options Gorry: A revised ID expected shortly after this IETF, and will be subject to WGLC (no presentation). 4.4.2 Tom Jones/Gorry Fairhurst: DPLPMTUD for UDP Options draft-ietf-tsvwg-udp-options-dplpmtud This will be WQGLC'ed at the same time as above (no presentation). **5. Individual Drafts** 5.1 Michael Tuexen: SCTP/UDP 6951.bis (10 mins) draft-tuexen-tsvwg-rfc6951-bis (see slides) Document created after consulting with AD. Michael: Can we request WG adoption? Gorry: I encourage this WG to give feedback on this; it should be of interest. We are looking forward to see a future presentation. 5.2 Michael Tuexen: Zero Checksum for SCTP (5 mins) draft-tuexen-tsvwg-sctp-zero-checksum (see slides) Michael: The co-authors are willing to implement it into Chrome / Firefox. So there is some support from implementers. Also Wireshark support was added at the Hackathon. Michael: This is a simple document, could progress very fast, and people want to deploy it. Requesting WG adoption? Existing comments from Gorry, Mike, and the responses to the IANA questions will be integrated. Poll: Who has read this document? (result goes here - notetaker didn't catch it) Lars Eggert: You don't need an RFC to make this IANA request, it can be a "stable specification" for IANA. Gorry: Lars is correct. Poll: Who thinks this is useful work? 18 agree, 1 not raising hand. Martin Duke: I have not read these drafts, do we have WG capacity to do all this? Lars: The best home for this work is this WG, still. Gorry: The Chairs will monitor this work and will do an adoption call in the future when there are resources to complete this. Magnus: This makes sense, be clear of the purpose of the document. 5.3 Nicolas Kuhn*: Careful resumption of CC (10 mins) draft-kuhn-quic-careful-resume (See slides.) Slide 2/7: In a satellite network context, QUIC took a while to converge on the new capacity. Nicolas: QUIC WG concluded that the problem space isn't QUIC-specific, but rather generic for congestion control. So that's why we present now here. Summary: The ID authors are asking TSVWG if it is willing to work on this? Piers O'Hanlon: The signaling has been looked at already in a proposal for TCP. Nicolas: We wanted to have metrics in which the client could participate. Piers: TCP metrics measures timeouts; this works reasonably well. Gorry: People, please send an email to the list with details, that would be helpful. Martin Duke: We had discussed a CC WG possibility. There is a side meeting on THursday for that. Gorry: The Chairs encourage people to keep working on it, we'll find an IETF home for this. 5.4 Gorry Fairhurst: Guidelines for Internet CC (5 mins) draft-fairhurst-tsvwg-cc (see slides) Gorry (as individual draft author): I am requesting people to come and talk about whether IETF has made correct guidelines on CC so far. This I think needs to start with a 'design team' activity ideally. We want to make new (updated) recommendations or it could even conclude that the current ones are already right. Document structure was updated. It is now easier to read - and specifically tries to differentiate two types of congestion events. 5.5 Martin Duke: ECN Tunnels (5 mins) draft-duke-tsvwg-ecn-aggregating-tunnels (see slides) Martin (as individual draft author): I am looking for input. David (as an individual): I recommend to proceed, these seem like new topics. **6. Any Other Business (If time permits)** (There was no time left in this session.)