TSVWG, IETF 118, Prague, Autumn/Fall 2023 Session (1 hour) Monday, 6th Nov 2023, Session IV 1730-1830 Room Name: Congress Hall 2 1: WG Status and draft updates RFC's completed: None. With IESG: draft-ietf-tsvwg-ecn-encap-guidelines (IETF LC) Document Shepherd: Gorry draft-ietf-tsvwg-rfc6040update-shim (IETF LC) Document Shepherd: Gorry Drafts beyond WGLC: draft-ietf-tsvwg-sctp-zero-checksum Document Shepherd: Gorry Status updates on other WG drafts 1. Chairs: Milestones Notices and Related Drafts Liaisons: 3GPP Liaison Request - (SCTP & DTLS) Gorry https://datatracker.ietf.org/liaison/1847/ GSMA Liaison Request - (Multi-Path DCCP) Gorry Chairs: Announcements and Heads-Up 2. TSVWG Design Team to set Requirements for DTLS/SCTP See updates on mailing list. This team is cope initially to produce some requirements for this meeting, and to help direct the working group activities. Magnus: Would be good to rescope design team. Gorry: Original scope was to produce these requirements. Can this be completed before end of this meeting? Does it make sense to request that report over the next two meeting intervals? Magnus: TLDR: yes. Gorry: It would be useful to to for this dsign team to look into a suggested path(s) forward for the working group? Remote participant: Can we consider also the implications of satellite 3g with high latency, has sctp been considered in such a situation? Martin: That is mostly out of scope for this work, though the security updates should not much affect the performance characteristics of SCTP. Magnus: SCTP is robust on the Internet, and should not suffer too badly in that situation. Gorry: If there are security considerations, please bring them to the design team, more general considerations, please bring to the WG list. 3. Transport: Multipath and CC 4\.1 Raffaello Secchi: Careful Resumption of CC draft-ietf-tsvwg-careful-resume Presented some activities at the Hackathon prior to the IETF, building experimental implementaions of CR in Quiche, Fastly and checking interiop, also with P\{icoQuic. Michael: How long are path parameters stored? Raffaello: The draft does not say at present, we are thinking of the order 5 minutes, based on what is done in other specs. Christian: I have tried a jump at ull BDP, that is dangerous. So I alos tried an increase of window to half the recorded BDP, which then takes one RTT to grow to full BDP, but is safer if conditions have changed. Raffaello: I concur: A jump of a half BDP is chosen to be safer. Matt: Thinking in futrure: This parameter you would ideally learn from the history of previous restarts. Kazuho: We do full BDP with pacing, but that can be 2x overestimated, and so half may well be the correct value. 4\.2 Markus Ahmend: MP-DCCP draft-ietf-tsvwg-multipath-dccp Gorry: Markus, you have hackathon code, is that code still relevant to the latest spec? Markus: It is still, there are plans to modify the handshake in the spec, the code will be updated to match. Markus: Next steps are to confirm the draft contents with those who has reveiwe comments and ask for a WGLC. Session 2 (2 hours) Thursday, 9th Nov 2023, Session I 0930-1130 Room name: Congress Hall 2 1. Agenda Recap and Notices (10 mins) 5\.1 Tommy Pauly: Happy Eyeballs v3 Lars Eggert: Great update, we should do this. Why is v6ops the right working group? Tommy: v1 and v2 were in v6ops. They had great input on other things that need to be updated for v6 only networks. Lars: While it started in v6ops because of IPv4 VS v6, I don't see any growth there beyond v6, but on other layers such as TLS. Going to other groups where this work happens makes sense. Brian Trammell: Agree with Lars. This looks now very WITty (WIT is the new area), it is the canonical draft for the new area. If TAPS weren't going to close, this would fit in TAPS very well. Now, this group is the place to do the work. Martin Duke: Is there a critical urgency to publish this? Tommy: No urgency. The bit on SVBC we've been running for years. But, there's more discussion on how do we correctly incorporate the preferences around ALPN, there is still room for discussion and debate. Martin: The IESG will discuss it, or if not, DISPATCH. There's four different areas that could claim this. Tommy: Agree with Brian on WIT-ness. With area reorg, it fits better in WIT than other areas. But, the IESG should talk about the evolution of TSVWG within WIT. Martin: TSVWG is not the generic WIT place, it still focuses on transport. Gorry: As individual, this is interesting because it requires input from many groups and decisions from one group, I would like to hope we can continue to develop the work with visibility in multiple places. 2. ECN & L4S Drafts 6\.1 Jason Livingood: L4S Experience (20 mins) Jonathan Morton: The results overall seem similar to deploying Cake. How vigorously are you looking at the harm that can result to innocent bystanders? Jason: Very vigorously. The users monitor their regular activity and report any issues. Jonathan: That's the participants. What about bystanders: people on different networks that don't support L4S but receive spillover L4S traffic. Jason: We haven't seen any effect. We've got network statistics and analytics at interconnection points and other places in the network. Jonathan: Slide 4 - you're using a DSCP, bleaching distorted heavily-quoted statistics on ECN deployment, I am questioning justification for using ECT(1). We could have run this experiment years earlier using DSCP. Jason: Most networks have their own proprietary use of DSCP, we made sure to fix bleaching. Chris Box: Thank you for sharing these results. What are the Cloud-native apps? Jason: Cloud Gaming, but we have internal theories on Cloud-based collaboration apps, which may see a bigger benefit. Chris: Network responsiveness results slide 14 - what do these RPM changes mean? Jason: Challenges - users needed to run latest version of macOS, enable L4S in network quality test, some of these were confounding issues. We were hoping to see higher RPM numbers. The numbers on the right are three different customer examples. Lars: Any there other effors for customers not in the US? Jason: Greg White has been running interops, and had a variety of equipment vendors attend and expect to see PON and 5G demonstrations, I don't know where these networks are. Greg: There's a lot of interest and network operators planning deployment, but so far Comcast is the only one that has announced a trial. Jason:  Part of my 2024 plan is to talk to other operators. Dan Druta: Sign me up. Any results on connections from other devices in the home, such as Wifi routers, switches, that homeowners install and that are out of your control? Jason: Good suggestion, we'll make sure we do that. Subir Das: Slide 4 - You tested Facetime and gaming. Why put everything on AC\_VI on Wifi? Jason: It is in a recommendation document to use a different WMM class than AC\_BE. Each of these queues has different types on config. Subir: Are you following RFC 8325? Gaming and interactive video would be in different classes. There should be separation. Jason: The main place where this happens is on downstream side. On the upstream side it'll mark however the client wants to mark. Tong Meng: Great results, looking forward to more, such as 5G. How do you set CE marking thresholds? Jason: Most of that is done on the client side, the application software can implement it in different ways. Greg: On CE marking threshold, one of the config file changes will roll out soon. Currently a very low threshold, so there might be some excessive CE marking. Intention is around 2ms of buffering delay. Tong: May not be the best option to set CE marking to same threshold for all networks. We have conducted tests with L4S, we see non-congested behaviors in 5G the latency will not decrease to a super low value, there are negative effects to throughput and bandwidth efficiency. Greg: Yes, in networks where capacity varies rapidly, there can be a benefit to having a larger CE-threshold. Madhan Kanagarathinam: Gaming latency, once we put packets into AC\_VI the network will prioritize. Did we ensure we benchmark the default case, was it also in AC\_VI? Plans for testing with Android or other devices? Jason: Android - we have users running Android, we haven't run any specific tests, if you have any we'd love to talk. First question - testing we've done so far is only upstream, once we get the packet off the Wifi, we're looking at marks and putting it in the low-latency queue, if client has marked AC\_VI or AC\_BE, it gets handled however the Wifi wants to handle it. We haven't been able to set that. Once we do downstream testing, we may see the difference. 6\.2 Greg White: L4S Interops and L4S Operational Guidance (10 mins) draft-ietf-tsvwg-l4sops Lars: Have you had meetings at NANOG or RIPE? Greg: Have not had, interesting idea. Thank you! Gorry: This draft bis targeting publication Nov 2024, please be sure to add any more experience. 6\.3 Greg White: NQB (10 mins) draft-ietf-tsvwg-nqb Gorry: People who will review? I see one. Looking for people volunteering to review the final text, please let Greg or me know. Gorry: Please comment on the mailing list or Github. 3. SCTP Drafts 7\.1 Michael Tuexen: Zero Checksum for SCTP (10 mins) draft-ietf-tsvwg-sctp-zero-checksum Gorry: WGLC will end formally today. This is your last chance to send comments. The doc creates a registry which allows non-IETF documents to specify transport behavior. We will consult the IESG. Lars: What's the IANA policy? Michael: Spec required, expert will review. Lars: What is an indication of how much CPU the CRC32c is using? Michael: Users using datachannels disable checksum on receiver side, gain up to 30% CPU. Lars: That seems high. Michael: These were low-powered boxes. ARMv8 has support for special instructions for doing it, but they were on smaller boxes. I know of a product that substantially reduced the CPU amount, couldn't do what they wanted with the checksum enabled. 30% was the worst case. Jonathan: Never underestimate software engineers to introduce bloat. 7\.2 Michael Tuexen: SCTP AUTH 4895.bis (10 mins) draft-tuexen-tsvwg-rfc4895-bis Gorry: Chairs think this falls in our charter. Who has read this document? At least four people. Please hum or indicate remotely if you think this topic of maintaining the spec is one we should address. I hear a small hum. Please hum if not. I hear nothing. Please use the tool now. Who supports adoption of this draft as work item in this WG? 15 Yes, 2 No. People who said No: please speak up. None wished to. We will repeat the adoption call on the list and confirm. 7\.3 SCTP & DTLS (5 mins) Michael: The design team will meet after this meeting. Gorry: This will be an informal meeting. We will have additional design team meetings scheduled with remote participation. Should end at the end of December. 4. UDP Transport 8\.1 Gorry on behalf of chairs: UDP Options (15 mins) draft-ietf-tsvwg-udp-options draft-ietf-tsvwg-udp-options-dplpmtud Issue #16: Decision whether to send ICMP messages? Wolfgang Beck: I think it would be a bad idea to have ICMP feedback. If you have oversized UDP packets, you have other feedback like RTCP. Other protocols like DNS or SIP, they have their own timeout mechanism. I would prefer solutions that simply drop the UDP fragments. Gorry: I understand, just let the application deal with it. Two notifications of fragmentation is a bad side effect. Mike C. Heard: I concur. Christian Huitema: The main thing you should do is set the Don't fragment bit. Gorry: These are not IP fragments, but individual UDP packets that can't set DF. They are fragmenting a larger UDP datagrams at the sender into two smaller UDP packets, each with an IP header. Christian: You should do what QUIC does, it has its own packetization on top of that. Gorry: Yes, this is orthogonal, it's about fragmenting the payload on top of that. Christian: I think I concur with everything that was said before. Martin Duke (no hats): Fragmentation is confusing. If I think of it that way, ICMP is a layering fragmentation, because it's about IP layer. Gorry: It's possible to have a UDP layer ICMP. But we'd need a strong reason to do it, I'll ask an INT area AD for comment. - Mike: The current -24 didn't get some of the issues that are currently closed fully addressed. \#21 is our biggest bug bear, modulo the issue of AUTH not being ready, which I agree on. Those two are specified correctly in the architecture in this version, but they defy expectations, the WG needs to decide if we want these things there at all. The easy thing is to drop them. On the rest, we seem to have agreement in principle. Gorry: Keep some of that text to capture the dicsussion, but not specify a code point? Mike: Hard to argue with that. Gorry: Let's do a WGLC ASAP. Please contribute and review. 1. Individual Draft 9\.1 WG Chairs: Heads-up notices on proposed future work (10 mins) 9\.2 John Kaippallimalil: Metadata for a Media Packets (15 mins) draft-kaippallimalil-tsvwg-media-hdr-wireless Gorry: When you say the values of these fields change per packets. Are they mutable or immutable in network? John: They're immutable. Gorry: We are not considering an adoption call at this meeting, but we will ask questions to the group. Dan: I'm interested in the subject. What is the overhead of per-packet information that needs to be updated quite frequently, on the media server and the wireless node? Are the media server providers willing to play along? How do you plan to encode those three elements on a per-packet? I've seen patterns where the expectation is one piece of information, you are expecting to send three. John: The overhead is 18 bytes, if we add an auth option that's in addition. In terms of updating things, we defined it to be flexible. Relative priority is pretty easy to provide, the other options are burst size and delay, which may not be so easy. The data is flexible of providing one or more. The idea of having something in the IETF is to allow many application providers and wireless service providers to have a common framework as a basis to do this. But yes, there are tradeoffs, we'll need to look at them. Magnus Westerlund: One of my concerns is related - to process this in the wireless network you need to keep state and the information is longer than your buffer depth. I look forward to this, some of these questions have a lot of impact. Martin, no hats: Media providers - SADCDN folks are largely content providers who are trying to solve similar problems, please align with them. I do appreciate how this has migrated to UDP encapsulation as an explicit channel between endpoint and network, easily lets plug in DTLS, privacy, authentication. This could be better than using UDP options. Hang Shi: Use case is valid, can be separated in two parts: What metadata and where do you put it. If we agree on encapsulation, where we need to defer to which protocol. Tianji Jiang: I know the background from 3GPP. It's one of many possible options, it's a good one. Marcus Ihlar: Agree with Magnus - listen to 3GPP, there is a lot of work on the applicability. You have to think a lot about the trust model, as you can allocate resources on the radio. Ruediger: I'd appreciate discussing DiffServ more in the draft. You could signal up to 64 signaling behavior. Gorry: Please hum if the topic of per-packet signaling is a topic where you'd like to see work done. Please hum if not. I heard some hums both ways, maybe slightly more for the first one. Who would contribute to this work? Please use the tool. Not support it - Would you work on it or review it? 12 Yes, we saw 28 people interested at the last IETF. We'll use the WG list to develop more thoughts on this. 2. Any Other Business (1 slide each & discussion, if time permits) draft-yao-tsvwg-cco-problem-statement-and-usecases-00 draft-yao-tsvwg-cco-requirement-and-analysis-00 draft-jiang-tsvwg-slice-media-service-01 (Out of time for the above.)