# TSVWG @ IETF 116 {#tsvwg--ietf-116} Chairs Gorry Fairhurst & Marten Seeman Notetakers: Reese Enghardt & Ana Custura ## Tuesday Session I (2 hours) {#tuesday-session-i-2-hours} Room Name: KG401-G402 1. WG Status and draft updates RFC's completed: draft-ietf-tsvwg-ecn-l4s-id Published as RFC9330 draft-ietf-tsvwg-l4s-arch Published as RFC9331 draft-ietf-tsvwg-aqm-dualq-coupled Published as RFC9332 RFC's in Queue: draft-tsvwg-dscp-considerations RFC-Ed Shepherd: David Note - the Charter milestones have been updated. 1. Notices and Related Drafts Work related to TSVWG: draft-livingood-low-latency-deployment draft-duke-tsvwg-ecn-aggregating-tunnels draft-fairhurst-tsvwg-cc draft-ietf-tcpm-accurate-ecn-23 (WGLC in TCPM) 1. WG Differentiated Services & AQM Drafts 3\.1 Greg White (remote): L4S Operational Guidance draft-ietf-tsvwg-l4sops Greg: The main discussions are about the name of the document and about fallback. We had a suggestion from Michael, and a response from Rüdiger on the list, but would like consensus from the Working Group. Gorry: DO you have suggested text? Greg: There is no suggested text so far. The ideal place to describe fallback would be RFC 9331, but this is already published. So L4S Ops might be the best place at the moment. TSVWG Chair (Gorry): Does anyone in the room have comments on Rüdiger's and Michael's comments on the list? I don't see anyone in the room. The chairs will send an email to the list to solicit explicit comments on the text. 3\.2 Greg White (remote): NQB draft-ietf-tsvwg-nqb Completed a WGLC on draft -14, and now trying to address issues arising. The latest is -17 with all agreed changes, and we have 13 topics to be explored. Issue 21: Greg: I think we can look again at the numbers - most apps do not need anywhere near 1 Mbps. Gorry: Speaking personally, I worry about the IETF making statements of 100 Mbps as "normal", many people in the world don't have that. I also wonder if we really need this high a number for the draft to fulfill its goal. Christian Huitema: If you have to pick a threshold, pick low enough. For an uplink of 3 Mbps, 1% gives you 30 kbps. Greg: This is not to be interpreted as a threshold below wihch an application does not need to do congestion control, but a threshold below which an application can use a particular code point. The expectations is that all of the existing IETF guidance and BCP still applies. Jason Livengood: I always recommend a fraction instead of a fixed number. It gets around having to index something to inflation, a number may look ridiculous in 5 to 10 years. Given that link capacity varies dramatically, making it percentage-based makes it easier. Greg: Thanks, we'll keep the 1%, I don't think that's controversial. But the question is what's typical today to provide guidance to application developers. Stuart Cheshire: Agree with Christian about people in different places in the world. I also work on Wireless networking, THREAD, runs at 1/4 Mbps and requests 100 kbps once you take overhead into account. The Internet architecture spans a wide range. What might seem inconsequential amount of traffic to one network may flood another network. If a flow doesn't want to build a queue, the way to do it is use L4S and respect congestion marks. Giving any developers the false impression that they use NQB Diffserv mark and this means their flow doesn't build the queue, there's no magic, you only avoid building a queue by adjusting your rate. Application developers are treating NQB as a free pass to not implement congestion control. Greg: I'm hearing we'll make the text stronger around the expectation and the requirements of implementing congestion control. Bob: The draft makes it clear that you have to use congestion control, a circuit breaker would apply in the case we're talking about. I did a study in 2021 just pulling available data off the Internet on average bitrates around the world, the main data that is not there is variation in each country. If that were available we could do something like a percentile. But unfortunately, that sort of thing is not available. Louis Chan, Juniper: From the application perspective, if you say 1% of bandwidth, it may not be useful for anyone. If you just say 1 Mbps, it may be easier for the application to realize. And wireless rate can change a lot. You can limit it to some application just within the wired, rather than wireless. TSVWG Chair (Gorry): We'll use the issue tracker between the recent WGLC and what we hope will be the last WGLC. If you think there's anything raised in the WGLC that was not addressed in the recent revision and not now in the issue tracker, please check out the issue tracker. Greg will send a pointer to the mailing list. 1. Transport Drafts (DCCP, UDP & Other Transports) 4\.1 Markus Ahmed: MP-DCCP draft-ietf-tsvwg-multipath-dccp * Discussion on "concurrent path use", Discussion of intended document status Mirja: We as a community should not put useless normative language in the document. It doesn't change anything in the protocol, people will just do it anyway. Markus: We followed text suggested by the area director. At least it gives clear recommendations to the implementer, but if the implementer goes for it, I hope he know what he is doing. Mirja: This discussion was initiated by Martin Duke as individual, not as AD. The whole protocol is designed to enable concurrent use. This is why I find it useless to put this normative language in there. Gorry: Individual comment on the "SHOULD NOT be implemented": The IETF cannot tell you what is implemented, they can tell you what a protocol spec should be allowed to do, what is safe. I get the idea of declaring out of scope the concurrent use. Concurrent Multipath is not finished as a work item, and can't appear in a PS. I don't like the second sentence, which says, if you don't like this, here's the way to do it anyway, which makes the spec look experimental. Martin Duke: I don' think we need to agree about the wording here, but what does experimental mean? We don't know as a community that it is safe to use or beneficial, and that's where we are with concurrent multipath in terms of scheduling. If people agree with this statement, that's a discussion to have. If people want to word it differently, I'm fine with that. Of course, the same thing with QUIC, there's going to be more implementations. People will do what they're going to do, but somebody reading this naively shouldn't think these problems are solved. So thank you for doing this, Markus. Subir Das: Can we go to your experimental results slide? What is the meaning of the colors on the right? Are you sending packets on concurrent path? Markus: In this scenario, it's one path at a time, not concurrent. The open source implementation we use is also able to provide scheduling on a per-packet basis, but that's not what we do on this slide. Marten: Who has read the document? Please raise hand. Four, five people? I would like to do a hum. If you agree that this document should be changed from Experimental to Standards Track, please hum now if you are in the room, we'll use the tool for people who are remote. If you believe it should not be changed, please hum now. That was a lot louder than the first one. Remote poll: 8 "Raise Hand" for changing the track, 12 "Do not raise hand". Matches the room. Markus: People against moving the track should really read what we shared on the mailing list. The full text is on the mailing list. I would be very happy to get your feedback especially for the people who are against changing the track. Right now I have no idea why you are against. TSVWG Chair (Gorry): Martin's question about why it should be PS or EXP is exactly the conversation we should facilitate. Please don't take the hum or poll as an indication of the WG's opinion. There is a divergence of opinion. Please continue to discuss on the list. Markus: This is a question we need to resolve before going to WGLC. Please help us on the list. TSVWG Chair (Gorry): The level of review and scrutiny required to progress to publication will depend upon the document state. Let's try and work out that document state and then the WG needs to find committed reviewers, preferably including reviewers from the MP-QUIC community to make sure we're consistent across the RFCs. Motivating a change to PS has to be done by the editorial team. 4\.2 UDP Options 4.2.1 Joe Touch (proxy Gorry): UDP Options draft-ietf-tsvwg-udp-options The WGLC had concluded and had a discussion of changes. There were three basic issues to be considered by the WG: this will use RDOS (formally DOS); Maturity of Encryption and Maturity of Authentication. * Security Options Gorry: how should we address encryption, authentication? Should we start a new doc? Any feedback? Magnus Westerlund: I don't see why there is hesitance to put encryption, authentication outside the document. It's an incomplete specification, hard to understand, and this has the possibility to unecessarily delay the progress of the spec. Mirja (from floor): Agree with Magnus, we should publish this document as soon as possible, if we need to take this out as it needs more discussion. The only thing is if there's still enough energy to start a new document because I think we still need that. TSVWG Chair (Gorry): We did offer work on encryption technology as a part of this work itme - maybe so we can make more progress to work on security as a separate document where it may get more security input and review. TSVWG Chair (Gorry): There are now other documents depending on this, and we should ensure we have a pathway to publication soon. The chairs will work with Joe to find the best documet structure. 4\.2.2 Gorry Fairhurst (remote): DPLPMTUD for UDP Options draft-ietf-tsvwg-udp-options-dplpmtud This document had completed WGLC with issues. New revisions had been made, and the editors think these will address all the issues. Editors need to address something in the Introduction from Med; and confirm we have addressed the INTAREA review. TSVWG Chair (Gorry): Publication will proceed with the base spec, and we expect another WGLC as soon as that is ready. 1. Other Individual Drafts 5\.1 Nicolas Kuhn: Careful resumption of CC draft-kuhn-tsvwg-careful-resume draft-kuhn-quic-bdpframe-extension Ingemar Johansson: Interesting work. One of the pain points is when you have a shared last mile fixed wireless or fiber connection, capacity can change depending on the time of day. Perhaps something that needs to be experimented with. Nicolas: We have satellite scenarios on which we have done some experiments. There are plans for further experiments. To what extent being to careful limits performance - cubic and other ccs need explored, other scenarios might be different. Martin Duke: I took at look at the draft. I know you received a lot of instruction from QUIC, the draft is a little weirdly positioned, it seems to be about QUIC, but as a a companion to understand how to cache. I wonder if it is better positioned as generalised protocol advice, rather than QUIC-specific. Nicolas: We realized we still have QUIC in the title, as it was done with QUIC in mind, but it is more of a congestion control aspect than protocol specific. Martin: Yes, that's my impression as well, it might apply to TCP as well. Randall Jesup: I find this interesting. I played with similar concepts about 15 years ago. I think it can be useful to get to steady-state quicker when things work out. Minor point, the path could have changed when you resume, and the competing traffic could have changed as well. Another point, you have a fixed time, after which you throw it away and do a congestion ramp-up. Over time, your information about the state of the connection grows increasingly uncertain, this is directly related to the time since your measurements. I suggest you take that into account in your algorithm, perhaps by reducing the amount you jump the rate, as your estimate becomes more and more uncertain, as opposed to simply cutting it off. The last suggestion is measure the impact on existing flows when a new flow of this type comes into the mix, and what happens to fairness and throughput of other things on the bottleneck link in other situations, where it is or is not fully utilized. If you get to a steady state quicker. Nicolas: W have mentioned traffic change in the document, we will check to make sure we actually cover it. Reducing the value as a function of time is a good idea. For the impact on existing traffic, I just sent an email to the list with some experiments, we were very safe, we did less harm than slow start. But we need more experimentation, and this is something we need to list. Matt Mathis: I'm glad this work is happening, the restart behavior of TCP has bothered me for decades. A couple years ago, Keath Weinstein presented a REmy-TCP, an ML-based congestion control, he got better results than standard congestion control. Standard congestion control is close to optimal in many environments. I looked at this paper, all his workload was transactional, and the ML algorithm did a better job of estimating how to restart connections, than the default algorithm. This is one part where ML helps to adapt the initial rate when there is other traffic. You want to adapt how you restart to what happened in the past restarts. There is a huge research opportunity here. The standardization piece is the framework, there has to be some piece that is ML, which is outside of the framework. Nicolas: We have other work on using ML for detecting the rising congestion on the network, we send the paper to the list. Christian: I have been working on this. This protocol is focused on scenarios with long delays, we have even talked about communication to the moon or to Mars. If we do not get some guidance on how to do that, eager folks will just restart with the previous value of the parameters. How do we teach them to be somewhat careful so they don't whack everything, but get the benefits. I question about being too careful. Nicolas: It is easier to jump to the previous value, much more complicated to implement this kind of mechanism. The problem that we face when having this discussion, is that people ask why not just halve when we "retreat", why be much more careful. This is something we need to discuss... Christian: If you have a long delay link, you don't want to lose a full BDP of packets, that might need to be retransmitted later. It would be better to consider something more modern, like using the Hystart mechanism, detecting congestion rather than waiting for packet loss. Hystart might be important to try and avoid this crash. To Matt's point, this should be addressed in Not-congress because it goes with other IDs, there is also things like using chirping to quickly estimate the bandwidth, there is work we can do. John Border: I have been closely following the work. The main questions: How careful to be, and what kind of checks do we need to be safe. This work is important and would be great to see this wokr picked-up. Randall Jesup: Since this is going to be a protocol-agnostic algorithm, when you talk about what to do when you fall out of it, not just loss, but it could be an increase in delay, depending on the congestion control algorithm, so you can react more quickly. Much like the real-time congestion control algorithms. When you write it somewhat agnostically, do you can use what tools are available. Nicolas: That's a tricky part, when we use CUBIC and BBR it's different, it's hard to be congestion control agnostic. Martin: Show of hands, who has read the draft? 5 people in the room, and a few in the chat, at least 5 as well. Gorry: About positioning this work in the IETF, there are various places. If it's a modification to QUIC, could be QUIC, but probably it is more. Should it be done in a separate WG? The idea is maturing, the idea of a CC WG will be talked about in the next presentation, congestion control is becoming a hot topic. As Chair: This piece of work could be in TSVWG if it applies to more than one protocol. It would need to be consistent with work in CONGRESS and not violate with the BCP there. There could be merits to taking this work in TSVWG rather than a work item that has to follow the other WG and BCP document. I think we should talk about it in this WG today. Martin: It's hot off the press, the CC WG will be called the Congestion Control WG. I don't believe in holding up this document to wait for this stuff to happen. This is best as a generic document. All hats off, I would like to see it adopted. AD hat on, the proper place to adopt it is TSVWG today and then if and when the CCWG is chartered, if we have the bandwidth to do it, we can do it simultaneously with 5033bis. We're talking about a lot of the same people. TSVWG Chair (Marten): We'll do a hum: Should the WG adopt this work? Silence. If you don't think we should adopt it? Also silence. Poll for adoption: 29 want to adopt the doc and only 1 person who thinks we should not. Do people with issues wish to speak up on why we should not adopt the document? (Apparently not.) As always, we'll confirm on the list. 5\.3 Matt Mathis: Safe Congestion Control draft-mathis-tsvwg-safecc This is early work. I'd like to know if I missed something, and a sense of things that have been debated and rejected. End of session, please discuss on the list. 5\.2 John Kaippallimalil: Metadata for a media packet draft-kaippallimalil-tsvwg-media-hdr-wireless No presentation, see slides in proceedings. 1. Any Other Business (If time permits) 6\.1 Tiru Reddy: Encrypted Transport Protocol Path Explicit Signals draft-reddy-tsvwg-explcit-signal No presentation, see slides in proceedings. ## Thursday Session IV (1 hour) {#thursday-session-iv-1-hour} Room Name: G303 Note takers: Magnus Westerlund and John Mattson 1. Agenda recap and notices 2. SCTP Drafts 8\.1 Magnus Westerlund: DTLS protection for SCTP draft-ietf-tsvwg-dtls-over-sctp-bis draft-westerlund-tsvwg-sctp-crypto-chunk draft-westerlund-tsvwg-sctp-crypto-dtls Magnus presenting: Started with 3GPP requesting update of RFC 6083 with larger messages sizes. Found that RFC 6083 with DTLS 1.3 does not work with long sessions. Later found security issues with SCTP AUTH. During the work it has been realized that the current solution (DTLS over SCTP) has several downsides. Fixing DTLS over SCTP requires an update to SCTP AUTH. A lesson from SCTP-AUTH is to use existing security protocols as much as possible without changes. DTLS in SCTP is an alternative to DTLS over SCTP. Written up in two drafts. Works on SCTP packet level instead of user messages. It consists of two main parts. A new crypto chunk and then protection engines using the crypto chunk. State machine updates: PVALID chunk used to valitade engine negotiation. PVALID sent in protected state. If PVALID validates, data chunks can be sent in teh following ESTABLISHED state. Relay, rekeying, and multihoming are simpler to handle than in DTLS/SCTP. Especially rekeying is especially simple compared to DTLS/SCTP. DTLS responsible for retransmission of DTLS messages. Michael Tuxen brought up an alternative realization on the mailing list. Michael also brought up splitting up the DTLS implementation into DTLS handshake and record layer. This is done in some existing implementations, e.g., Netflix. Magnus thinks the split is an implementation question. Many benefits with DTLS in SCTP. Improved security, encryption of all chunks, improved replayed protection, rekeying is more robust, less dependencies on DTLS features. Michael Tuxes sais that he has not come up with how to implement DTLS in SCTP in the kernel in a nice way. Michael says DTLS/SCTP and DTLS in SCTP are quite similar at a high level. Michael says that some SCTP features cannot be used. Restart and ASCONF. Magnus agrees. Magnus said he will look into what can be done with ASCONF. This needs to be analyzed if not protecting ASCONF would be acceptable. Martin Duke: What is he proposing? Magnus says that yes he wants to replace the current DTLS over SCTP with DTLS in SCTP. Charles Eckel says that 3GPP will discuss in the April. The LS from IETF was delayed for a couple of months. Magnus said mailing list discussion is good. Gorry asked if any more than Michael has reviewed. Magnus says that Nokia will review but has not done so yet. Comment: the Linux people are not on the list, someone could reach out to them. TSVWG Chair (Gorry): It would be good to get more people to look at these proposals, if we're changing the direction, we will need to do a consensus call when we have a concrete proposal. 8\.2 Michael Tuexen\*: Zero Checksum for SCTP draft-tuexen-tsvwg-sctp-zero-checksum Michael Tüxen presented the slides. Martin Duke: Do we have any data for the cost of the CRC32c? Michael: It is measureble, in a SCTP stack only, it can be 1/3 of the processing. There are Intel NICs that can do offloading if one has a kernel SCTP stack. TSVWG Chair: Who has read the draft: Two in the room. TSVWG Chairs run a show of hands for adoption. 14 hands in favor of adopting the draft as WG item. We will take comments and any further feedback from the list and then consider adoption there. 8\.3 Michael Tuexen\*: SCTP-Auth 4895.bis draft-tuexen-tsvwg-rfc4895-bis Michael gave a short overview of the status. He plans to do the fixes before the next IETF meeting. Magnus Westerlund noted that if DTLS in SCTP is not chosen then there will be critical dependency on the updates. Michael stated that this needs to be addressed anyway, but the priority will depend on the outcome of the choice for DTLS proteciton of SCTP. 8\.4 Michael Tuexen\*: SCTP/UDP 6951.bis draft-tuexen-tsvwg-rfc6951-bis Chairs asked who would be willing to review 6951.bis. Magnus and Claudio indicated that they would review the document. TSVWG Chairs run a poll on interest in this document. 8 raised their hand and none did not raise their hand. Gorry stated next step is looking for a set of reviewers and we can then consider an adoption call. 1. Other Individual Drafts 9\.1 Louis Chan: Enhanced Port Forwarding functions with CGNAT draft-chan-tsvwg-eipf-cgnat Louis Chan described the problem statement and need for Enhanced Port forwarding. TSVWG Chair (Gorry): Thanks for this worked example. Please consider this proposal and take questions and discussion to the WG mailing list. 1. Any Other Business (If time permits) John Kaippallimalil: Metadata for a media packet draft-kaippallimalil-tsvwg-media-hdr-wireless John motivated the problem. Session ended 17:32 Japanese time.