TSVWG Agenda Chairs: G Fairhurst, W Eddy (Remote) D Black (Remote) AD: Martin Duke Session 1: 13:00-14:00 Monday 21st March (1 hour) .1. Agenda Note taker: Stuart Cheshire (Notes were updated by meeting recording) .2. Chairs Update RFCs completed or in Queue: None. Drafts with IESG: None. Drafts beyond WGLC: [draft-ietf-tsvwg-ecn-encap-guidelines](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines) (Writeup Needed) Document Shepherd: David [draft-ietf-tsvwg-rfc6040update-shim](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim) (Writeup Needed) Document Shepherd: David [draft-ietf-tsvwg-ecn-l4s-id](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id) (Writeup Needed) Document Shepherd: Wes [draft-ietf-tsvwg-l4s-arch](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch) (Writeup Needed) Document Shepherd: Wes [draft-ietf-tsvwg-aqm-dualq-coupled](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled) (Writeup Needed) Document Shepherd: Wes ECN encaps ID is awaiting text before final write-up and new ID will be sent to the WG. ECN Shim Headers ID will be submitted with this ID. A few small points to be taken care of for L4S writeup and plan to wrap these commentrs up this week and submit to the AD a week after. Chairs: Milestone updates & Liaison WBA Liaison Request - (DSCP/5QI mapping) David A liaison response was sent about a year ago, and nothing currently heard from WBA on this topic. 3GPP Liaison Request - (SCTP & DTLS) Gorry GSMA Liaison Request - (Multipath DCCP) Gorry Chairs: Announcements and Heads-Up Work related to other WGs: None. New proposed work: [draft-romo-iccrg-ccid5](https://datatracker.ietf.org/doc/html/draft-romo-iccrg-ccid5) (Please discuss on ICCRG list; progressd of this is related to the BBR IDs) .3. Transport : SCTP & L4S 3\.1 Michael Tüxen: SCTP NAT Support - This discussed the way forward for the different proposals. - [draft-ietf-tsvwg-natsupp][1] (this ID was returned to WG) - Anissue is that on multi-homed SCTP hosts, a session can have multiple IP addresses, but only one port, which is incompatible with having different NATs on different paths do different port translations. - Gorry Fairhurst asked for comments from the meeting participants. - Martin Duke: What is Michael’s preferred solution? - Michael Tüxen: I like solution 2 (Always use a fallback mechanism) - Claudio Porfiri: (indistinct audio) - Magnus Westerlund: These are the issuesI see: Can we support multi-homing? Home many sessions? What is the complexity? - Cullen Jennings: I don’t see how solution 2 works. It is too vulnerable to a denial-of-service attack. - Michael Tüxen: Protection is because the state can only be created by internal hosts. - Chairs: We need to make a decision after this meeting, please follow-up on the list and we need to call-out a way forward for this item to the group. 3\.2 Magnus Westerlund: DTLS over SCTP - RFC6083.bis - There was discussion based on decision whether or not to make a bis version that obsoletes the RFC6083 spec. - [draft-ietf-tsvwg-dtls-over-sctp-bis][2] - Gorry Fairhurst: Is obsoleting RFC 6083 a separate question we can discuss later? - Michael Tüxen: I agree RFC6083 needs to be updated. I am concerned about Ericsson’s IPR declaration on this draft, and that the suggested work item would prevent open source, which has corrently been possible for SCTP spec. - Magnus Westerlund: We do need to make progress for a use by 3GPP. There could be two IDs, anothger one a simple update to RFC6093, allowing this to progress in parallel. - Michael Tuexen: We might need to start a new draft that avoids the Ericsson’s IPR claim as a replacement for RFC 6083. - Magnus Westerlund: Would you be willing to work on an alternative to RFC6093? - Michael Tuexen: I would work on an update that obsoletes RFC6093, if there are people wish to join me. - Gorry Fairhurst: This Working Group needs to decide on this after the meeting: We could decide not to update RFC 6083, and whether a parallel spec would be acceptable by the WG. - Chairs: We expect the current work item can continue in tsvw, but we do need to take the question of whether this item will finally obsolete RFC6083. This is a question for the list to decide, and implies that it is possible that a different work item could then update RFC693 in future. It is also possible that at the time the current work item becomes RFC the IPR and open source experience has changed during that time. - Martin Duke (AD): Open source has been important in the past. I see 3GPP needs the new spec. At the moment it seems unclear how RFC 6083 and this will coexist, but that doesn't need to stop progress. There doesn’t currently seem to be much enthusiasm for writing a separate update to RFC 6083. We do need to make progress. - Magnus Westerlund: I don't think it is impossible to have two parallel version, and the policy and startup will define which version is used. (Extra slides decribed some future issues for the ID, but were not presented, which will be discussed on the list.) - Chairs: In the future, the IETF will need to do security maintenance of any security-related IETF protocol, so if we finally decie to leave RFC 6093 still as an active RFC, we can expect a minor update to be needed. We will ask the WG as a whole after this meeting to seek an acceptable plan to take this forward. 3\.3 Greg White: L4S Operational Guidance [draft-ietf-tsvwg-l4sops][3] - There was discussion on whether this ID is ready to publish, and then whether the WG should publish sooner than the current milestone. The original plan was to keep this as an ID during the L4S experiments, teh current text seems ready, is this still the plan? - David Black (individual): I think we should publish this as an RFC with the L4S or immediately after their review by the IESG, and then immediately begin work on a subsequent “bis” document to collect lessons learned from the experiment as we learn them. I think this is stable, and getting this seen by people is good. - Martin Duke (individual): How long does this L4S experiment continue? When is the experiment over? The L4S experiment will continue until the IETF publishes a PS. Are we expecting operators to be able to deploy this in months or years? - Greg White: I would anticipate a small number of years before we have significant experience, not weeks or small numbers of months. - Mirja Kühlewind: Agree, that we should publish now. - Chairs: We would like to see this document completed and will ask the WG after the meeting if there is agreement to publish this as an RFC sooner, and then open a new .bis document if this is needed to collect the lessons learend. Session 2: 10:00-12:00 Friday 25th March (2 hours) .4. Agenda Review Note well Note taker: Reese Enghardt (Notes were updated by meeting recording) .5. Transport : DCCP 5.1 Markus Amend: MP-DCCP draft-ietf-tsvwg-multipath-dccp - Lars Eggert: Have you started discussing with Linux Netdev community about upstreaming? - MA: At the moment, it is out of tree, which makes it easier to get some first experience. - LE: For MPTCP we could not really use it because we needed to build custom kernels, and if you want to run it with containers, it needs to be in the Linux kernel by default - MA: We are aware, but we need resources. Karlstad University is also working on a user space implementation. I am not sure how mature this is, but may be next IETF I can present something? - LE: This should not stop the IETF from working on MP-DCCP. - Michael Tüxen: IPR needs to be considered: What is the relation between this IPR and the open source code? - MA: That was declared before WG adoption. It targets being a part of Linux network stack, so it is GPL based. - MT: So, no IPR. Thanks. Tianji Jiang: This is one study topic in 3GPP, including multicast and how many paths can be supported. MA: We support as many paths as are available, no limitations. TJ: For MP-DCCP, will you support a proxy? MA: This maybe somthing that needs to be clarified in 3GPP, at the moment. From the draft, there is no support for this. It is also not the idea of the MP-DCCP protocol. TJ: OK, thank you. Chairs: There is an open side-meeting after the current TSVWG to provide additional information about the possible directions for IETF work to support the ATSSS work. David Black: Question in chat: Is there support for remote participation? GF: There is no remote participation support for this meeting. The organisers will make notes and distribute slides. This is an information distribution meeting, no decisions will be made. Martin (AD): No remote support for sidemeeting is policy by IETF. Other means can be used as the organisers see fit. Toerless Eckert: Is this TSVWG endorsed? GF: It isnot endorsed, it is only related. We just booked a side-room with space. Lars Eggert: Someone could fire up a webex or zoom. Gorry is right though that the IETF does not provide this. .6. Differentiated Services 6\.1 Ana Custura: DSCP Considerations draft-tsvwg-dscp-considerations Martin Duke: Thank you for doing this draft. The grid of DSCPs that you showed makes it clear we're burning the last useful codepoints, which is pause for reflection. I encourage you to take this presentation to OPSAREA. You may not reach the people who are still bleaching the DSCP (or ToS priority) because they are usually less connected with the IETF, but still this is a good entrance point into that community. AC: We will revise this draft to the next version. MD (AD): Are you proposing an additional draft? What is the new draft? GF (as individual): The current work item is Informational, and that seems appropriate until we start clarifying that this RFCs are updated based on current practice. Maybe Brian Carpenter's recent post on the mailing list was a useful to start about how we should think about codepoints after 20 years. Maybe this could be a document pair, with the recommendations as BCP or PS, that could be a change for DiffServ architecture. It would be good to get discussion on the data that Ana had. I don't think this blocks the NQB work item, but then we will not have many codepoints left. MD (AD): Please engage the operator community to address the bleaching situation. We made need an idea to increase the number of usable DSCPs. GF (as individual): Note the non-IANA assigned DSCPs are local use and experimental. There are various network usages: Some networks just pass the DSCP without making changes; Some make changes that are historically-based, but potentially harmful. Some have configured policies. Rüdiger (RG): I am configuring bleaching at my employer. I appreaciate work on an update to the existing drafts, and contributed a lot of my expierience. I would like to see some defaults for the access (optimize for performance, latency, bandwidth). May people come and ask exactly for that? GF (as individual): We can include Rüdiger's comments in the draft. RG: If your document updates the DiffServ spec, we appreciate that. Jonathan (JM): I want to express support for some BCP or diffserv-RFC update, discouraging the use of bleaching in the network in some effective way. GF (as chair): Ana, please revise this draft, consider presentation to OPSAREA, also let's probe all about what we mean to see if we can get consensus on DSCP recommendations. We expect these can be different timeframes. Bob Briscoe: You should also look at the IEPG meeting on Sunday. Talk to Warren Kumari or Lars Eggert. They meet every Sunday arroud IETF meetings. Ana: Please introduce me. Subir Das: Do we need an operator survey? Will the recommendation come to TSVWG or somewhere else? GF (individual): We can launch an operaters survery. They have worked quite well in the OPSAREA. Any diffserv recommendation will come from this working group. Other groups will have to be involved when we change the reommendation. SD: That recommendation will imply a new look at DiffServ architecture, right? GF: It looks like it might. DiffServ was implemented 20 years ago to make something work when nothing worked. Now we have something working, we might want to make (small) changes to make it work well. Jake Holland: I echo Martin, this presentation was really good. I would encourage you to take the data also to MAPRG as a measurement presentation. Not just the operator community, also the rest of IETF community and research community will benefit from this. 6\.2 Greg White: NQB draft-ietf-tsvwg-nqb Gorry Fairhurst (Individual from the floor): Thanks Greg. I think the whole DSCP thing can be dealt with. I like the change of the two registry names, that's probably right. I wonder if we should add some text about why we are doing this, and also to clarify what the use of the aggregate or low numbered DSCP (5) means when we later have allocations in the same column in Ana's table. They don't affect NQB, but may affect the SHOULD/MUST language around remarking. GW: Right. I agree we should get conesus on the SHOULD/SHOULDN'T wording. Also what is the end-to-end philosophy going forwards? Is Diffserv AS specific, or for end-to-end use? DB (individual): For the history - Diffserv tried to be both, allow individual networks to configure locally, the end-to-end did not work out all that well though. GW: David, do you think we're near WGLC? Looks like framework is close and we have to pin down text around code points. Anything else we need? DB: That's about it. Will want to take a close look at what we want to call these two new codepoints. Sebastian Moeller (SM): What is the timeframe for the DSCP 45 assignment? If NQB becomes popular and supported ubiquitously, keeping DSCP 45 seems not needed - this is only to fudge NQB into existing/future-legacy WiFI deployment? GW: What is the timeframe?: Applications mark the traffic with NQB while it is not formally assigned, one developer needs to use an alternate codepoint. I think there is demand for the codepoint sooner, rather than later. GF: Maybe part of the question is how long do we need the allocation for? e.g.: Do you think DSCP 45 will work end-to-end across the Internet in 5 years time? Will all the WiFi will be updated within 5 years? DB: Which version of "NO" do you like to hear (on all WiFi gear being updated)? GF: We don't know what's being adopted by who, the WG just makes suggestions. David: As the draft is written, DSCP 45 is long term, because that is recommended. Chairs: Greg, please work with the Chairs formulating the questions so that we can clear this issues up, and be ready for WGLC. .7. Transport : UDP 7\.1 Tom Herbert (TH): Checksum Offload Toerless Eckert (TE): Is there any good data on what the biggest reasons are for checksum errors and their probabilities? The use case always escaped me from the analysis. TH: Yes, there has been a lot of work, beyond scope of this presentation. The checksum will detect all 1-bit errors, stronger than parity, but weaker than a CRC. TE: I was just wondering what is the most simple answer to what actually happens and how to protect against it. What's the source of the errors that it does protect against? In UDP we had discussions on when the checksum can be omitted. Coming from network side, I never looked into end-to-end, which is the expensive part. TH: I suspect it is in the network. Modern computers have ECC memory. Memory corrupution is more likely, not super likely. For security purposes. Ethernet CRC has much higher protection. In UDP options the checksum can differentiate between standtard and non-standard use case. This can still be useful, but maybe not expected. Richard Scheffenegger: We have checksum errors on the order of once a year, with fairly old network gear. When you have undetected multi-bit errors, which then show up in higher layers of the protocol, you do have CRCs that will flag a bad transport. Jonathan Morton: Observation: The checksum delta technique is very useful for updating fields in the IP header for example that commonly get changed en-route. The ECN field. There can be bugs in the implementations. Certain packets have incorrect checksums while the rest are correct. If you use this technique, make sure to get it right. Problems can be hard to notice. An incorrect checksum has the same effect as a dropped packet. TH: Yes. GF: Does the set of changes which we put into the UDP checksum make it easier to offload, since the last revision? TH: When the stack basically creates a packet it will know where the checksum is. It is not super critical for it to be in a fixed location. But a device may also have constraints. It is likely that the offset may have to be within the header of the packet. Devices may only have 1 byte offset fields. Real estate in the transmit descriptor is very expensive, we assume that checksum is 2 byte alignment, of 256 values - we can double that, the checksum can be up to 10 bytes into the packet. Having a fixed location is not as relevant as making sure this is aligned to offset of 2 bytes and keeping it in the header of the packet. Obviously for software stacks this is not so relevant. There may be instances on older systems that do not like unaligned operations. All currently defined protcols have the checksum start should be 2-byte aligned to avoid any issues. Gorry: Yes, I think that alignment is in the current draft? TH: Yes. There might also be a misnomer in the context of UDP encapsulation and options. When someone makes the checksum optional, that is not necessarily saving cycles or performance, it can make this worse. UDP encapsulation where RFC 6935 or 6936 allows checksum errors even for IPv6 and states that a checksum is required, from a host point of view. If someone sets checksum to 0, we still have to compute the checksum when there is an embedded TCP packet: we still have to offload the checksum. In some legacy checksum algos we still have to go through the whole calculation on the host, which is where performance drops. The checksum we absorbed on the host, there is little performance gain to disabling the checksum from host perspective. The benfit is if devices like routers are communicating and terminate IP, and then they may not have any offload. Gorry: Presuming also when they are doing re-encapsulation. TH: We have absorbed the cost of a TCP UDP checksum, that's not a current problem we have. But as new protocols are introduced, how do we continue to leverage those? This is where implementation becomes most important. 7\.2 Joe Touch (proxy Chairs): UDP Options draft-ietf-tsvwg-udp-options Tom Herbert: What is the state on the implementation of this? GF: This is a question to Joe and the WG in general. I have not heard of implementation for the latest version on the mailing list, please bring it there. The general concept was implemented in an earlier version. Tom Jones will speak on DPLPMTUD, who implemented this outside of mainstream to demonstrate it's feasible. This WG would love to see hackathon activity and implementations. TH: That's what I was expecting. Chairs: When we have a complete revision that is coming, we expect document to be stable and at this point we invite people to review this. Tommy Pauly and Colin Perkins have agreed to do an early protocol review from the transport perspective. This is a new transport protocol, we have done this type of review before for DCCP and SCTP. We then expect a further revision and then WGLC. Please provide comments. 7\.3 Tom Jones/Gorry Fairhurst: DPLPMTUD for UDP Options draft-ietf-tsvwg-udp-options-dplpmtud Chris Heard: I have read this document, I did not post comments to the ML because I did not have any, it's really good. Did you envisage that the DPLPMTUD could be implemented as a shim layer on top of UDP options, rather than be integrated into it? That would influence what we specify in an upper layer interface? This has not yet gotten sufficient attention and scrutiny. TJ: I am not really sure what is the question: If you are using the UDP options, then there is not really a shim. The service to the upper layer is a value that is offered to the application. I do not know how you see the shim. Maybe you can clarify further? CH: I will write the question in an email... Chair: This work seems nearly finished. Please review and give comments on this document. The meeting closed. Please continue discussions on the tsvwg list. [1]: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp [2]: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-dtls-over-sctp-bis [3]: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4sops