TSVWG at IETF 104 Prague Monday, 25th March 2019, Afternoon Session II 1610-1810 Room Name: Congress Hall 1 WG Chairs: Gorry Fairhurst, David Black, Wes Eddy (remote) Note-takers: Brian Tramell, Yingzhen. Session I 1. Agenda 2. Chairs Update: RFC's completed: draft-ietf-tsvwg-rfc4960-errata (AD) Document Shepherd: Gorry Drafts beyond WGLC: draft-ietf-tsvwg-le-phb (IESG) Document Shepherd: David draft-ietf-tsvwg-fecframe-ext (IESG) Document Shepherd: Wes draft-ietf-tsvwg-rlc-fec-scheme (IESG) Document Shepherd: Wes Drafts awaiting WGLC: draft-ietf-tsvwg-ecn-encap-guidelines (Need reviewers + another WGLC) draft-ietf-tsvwg-rfc6040update-shim (Need reviewers + another WGLC) 2.1 IANA Registries No updates. 2.2 Milestone updates No changes. ECN encapsulation drafts are being prepared for WGLC before next IETF. L4S drafts are being prepared for cross-area IETF. PMTUD framework is targeting WGLC after next IETF. 2.3 Announcements and Heads-Up MISSREF*R(1G) document in C238 has been overtaken by LE-PHB 2.4 Implementation (Feedback from Hackathon on experiments) Bob Briscoe: On TCP-Prague: 80-10 people have been patching Linux for L4S and QUIC-Prague. We have built a virtual test environment and been looking at offload engines for Linux. Tom Jones: Seven people have been working on basic support for IPv6 HBH headers that follows on things presented last IETF. There is still work needed to see how signals can be integrated into transports. Jake Holland: Has any work been done on Accurate ECN and RACK? Bob: This was mainly the place where GSO was worked upon. This code is also useful when you have not been using L4S. 2.5 Other Drafts Related to TSVWG draft-eastlake-sfc-nsh-ecn-support - For info (Please discuss on SFC list draft-li-tsvwg-loops-problem-opportunities - For info (Discuss on TSVWG list) There is a side-meeting on Wednesday regarding loops. There are also various drafts in INTAREA, including: Tunnel encapsulation, GUE, and draft-olteanu-intarea-socks- 2.6 Vincent Roca: RLC Fecframe draft-ietf-tsvwg-rlc-fec-scheme draft-roca-tsvwg-tinymt32 This draft was introduced to solve an copyright and Licence. Adoption is requested by the Chairs at this meeting. The code was also updated to clarify ambiguities in representation of negative numbers. Spencer: IESG evaluation also looked at portability of the code, and this addressed the need to work in multiple environments. 3. Transport and Network 3.1 Gorry Fairhurst (editor): Impact of Transport Header Confidentiality draft-ietf-tsvwg-transport-encrypt The document has completed SecDir review, and updated were described. Authors plan to update the summary. Aaron Falk: I have not read the draft. Is this document making recommendations? I am concerned that this draft may be published and it may never be acted upon. Tom Herbert: This document describes the impact, but people may not act on it. I think encryption is coming. What is the solution? We could use extension headers to restore visibility of encrypted info. Gorry: I think we could. This provides understanding of why people are currently using transport header information, and potential impact and pathways for evolution. This ID does not solve problems. Tom Herbert: I am not convinced protocol development relies on this, google has deployed methods. It is rare that endpoint developers look at the network details when deploying new features. Spencer Dawkins (as AD who is stepping down): This draft is valuable as a description by transport experts of what is being done. This sort of background is a really helpful basis for pointing to when we start to do all the new things we have talked about. Gorry (ass editor) Can we start a WGLC please? David; Yes. The Chairs need to coordinate on the order of conducting the WGLCs in the period up to the next (Montreal) IETF meeting. 3.2 Bob Briscoe: Low Latency, Low Loss Scalable Throughput (L4S) ECN drafts draft-ietf-tsvwg-ecn-l4s-id draft-ietf-tsvwg-l4s-arch draft-ietf-tsvwg-aqm-dualq-coupled The ID now has a section to indicate that Fair Queueing AQMs can support L4S. We have dual queue code for Linux, Curvy RED implementation is not yet public. TCP Prague is Linux only. Running TCP Prague code should be configurable to meet the RACK-like reordering requirement. Bob would be interested in understanding if existing CE-marking is from FQ systems (where there is safety from other flows). There have been a number of supportive and non-supportive reviews. Michael Scharf: I am also one of the non-supportive people. Gorry: It could be helpful to add a separate section in the document how an FQ system could be updated in the next version. Bob: We plan this. Chairs: How many people had read the L4S Architecture draft? — About 15 Chairs: How many have read the Dual Queue draft? — Slightly less. Chairs: The Chairs would like to hear whether Dual Queue AQM can be implemented without the declared IPR? Bob: There are three IPR declarations. Chairs: Please come to the Mic or discuss this on the working group list. Bob: As a personal note there is a GPLv2 licence for the Linux version of the code. Bob: You could use another AQM such as Curvy-Red. This has beed used in the high-speed switch. Rodney Grimes: Are all of the pieces to implement L4S documented in IETF? Bob: The only thing that's missing is queue protection (which is in pseudo-code in the DOCSIS spec). We will be sending a draft. There is also coming ns3 code. David: How close is TCP-Prague? Or QUIC-Prague? to solving the RACK requirement Bob: If you use pacing, this may be very close. Gorry: Will the next revision of ID and Arch be ready to send it to the INT Area review team for early review? 4. New Work 4.1 Jonathan Morton: Some Congestion Experienced (SCE) draft-morton-taht-tsvwg-sce This proposes an ECN field transition between ECT(0) and ECT(1) known in this proposal as SCE. The reverse transition needs to the prevented. We plan to look at the entire congestion control feedback loop, including at least a couple of sender reaction mechanisms to make sure that they do what is wanted/expected before and/or in parallel with experiments. Brian Trammel: How long do you think this may take? Jonathan: We are making reasonably rapid progress in a few months. Gorry: Do you plan to update the draft, and when can we expect the next revision? Jonathan: We plan to do that in a few months. David: Do Jake: I believe the SCE draft talks about rend feedback. How do you see the different feedback methods working out? Jonathan: I plan one document on SCE, and others describing its applications to AQM and transports. The receiver-side solution may not be the best solution. We also have ideas of using the former NS-bit or accurate ECN or some other options. Bob Briscoe: I think CE markings in this scheme are for backwards for classic compatibility. An end system that reacts to SCE is very unlikely to see CE-marks. Using a 3-level signal could happen in slow start, but you do not want the CE signal in this case. What is the behavior of tunnels of SCE with tunnels? Deployed tunnels that could revert ECT(1) from within tunnel to ECT(0) before RFC 6040 was introduced (e.g. L2TP). Jonathan: In that case, the SCE information could be erased. Classic ECN would then react, which would be safe to survive. Chairs: Please discuss on the list. 4.2 Greg White (remote): Identifying and Handling Non-Queue Building Flows in a Bottleneck Link draft-white-tsvwg-nqb-01 The goal is to identify and enable L4S for sparse traffic. This adds a Non-Queue-Building traffic class that is expected to be below the capacity. David: The idea of protecting queues appears to be a “SHOULD support”. We will likely have to be "MUST support" for redirection of queue building flows to enable operators to thwart theft-of-service attempts. Greg: It could be promoted to a “MUST”. Bob: This is a policy decision. David: Must implement. Operators can then choose to use or not. Chris: Where did loss come from in the (related) LoLa draft? Gorry: We should look at each L2 technology in turn to see how this would work. Gorry: Why do you propose a specific DSCP? Greg: I think this classifies in WiFi to map to an appropriate mapping. David: Please see RFC 8325 and please update the draft accordingly, which may need a normative reference. Greg: I am aware of this. Jonathan: NQB is not supposed to be a priority, but this seems to give it priority. Greg: We are looking to map to an appropriate category in WiFi, and this is how it may fit into existing deployments. Michael: This is the prefix as EF. I think we should have that discussion later. David: We should look at what RFC 8325 says in respect to these mappings. Paul: Do you have a good reference for other methods to identify elephants. Greg: If you know more, we would like to consider this. Andrew McGregor: DNS over TCP could use this, and should be looked at. Chairs: How many people have read one of the NQB draft? — half a dozen. Chairs: Please hum in favour of doing work on this topic? — a few. Chairs: Please hum if you are against doing work on this topic? - a few. The hum showing interest seems slightly stronger. Chairs: Please continue to work on this topic and discuss on the list. 4.3 Chair’s announcement The WG is requested to adopt Vincent's tinymt32 draft to solve the problems that arose at the IESG, unless there is objection. Please send comments, if any, on the list about this draft. 4.4 Markus Amend: Multipath DCCP draft-amend-tsvwg-multipath-dccp draft-amend-tsvwg-multipath-framework-mpdccp draft-amend-tsvwg-dccp-udp-header-conversion Spencer (as an individual): Please think about whether multi-path IP or whether multi-path UDP is needed. This is a hard problem, it needs to be solved once if at all possible. I think this may be a good place to dig. We are also looking at adding multi-path to QUIC charter, and held off because it is hard, a general solution would be very useful. Markus: The needs are different to the way MP-QUIC has currently been discussed. Propose to change the header to promote better transparency. Alan Ford: You said reordering is an issue for an unreliable transport? Markus: Excessive reordering is an issue. Tom Herbert: When you do implementation, please look at MPTCP and how they did this. Spencer: See TSV-Area in IETF-102. David: When you figure this out, please look at what was done in DCCP WG, and also request a UDP port if needed. Chairs: Please discuss this ID on the WG list to progress this topic. ————— Tuesday, 26th March 2019, Morning Session II 1120-1220 Room Name: Congress Hall 3 5. Transport Protocols and Mechanisms 5.1 SCTP WG Drafts 5.1.1 Michael Tuexen: RFC4960.bis Update draft-ietf-tsvwg-rfc4960-bis Completed nroff to XML format conversion of RFC5960 source text (rev 00). Revision 01 reformatted the document. The editors are now applying the changes from the WG Errata RFC as revision 02. Revision 03 will start to address the language and clarifications needed, this will be a document for discussion. Gorry: To be clear after 03, the WG could still potentially discuss new topics if there any important issues emerge. Mirja: Will this obsolete the Errata? Michael: No, that was informational. RFC4960 would be replaced. Chairs: The WG could choose to obsolete the RFC4960.bis or not later. We’d also like to ask if the WG would like to progress this along the standards track - that is something to consider nearer publication. 5.1.2 Michael Tuexen: SCTP NAT draft-ietf-tsvwg-natsupp Maksim: I was concerned about requiring all associations to be tracked. David: I think the suggestion is to track less state? Maksim: See detailed comments to reduce the hash table. Michael: We will discuss this topic and will revise for the next IETF. 5.2 Gorry Fairhurst (Editor): Datagram PLPMTUD draft-ietf-tsvwg-datagram-plpmtud The draft had been edited, and the state diagram simplified. This is now easier to read. Authors are trying to get more experience and understand implications of loss, reordering and other path issues. Martin Duke: Are there implementations? Tom: There are implementations of the framework, there are 5 or 6 implementations over the lifetime of the draft. Martin: What was the platform? Praveen: When QUIC references this will QUIC say this is the method to implement this. Gorry: QUIC allows PMTUD or PLPMTUD. The first QUIC spec is aligned to this. Christian: QUIC has authenticated feedback. Gorry: Yes, QUIC does not change the algorithm, and is described in the ID. Christian: It would be nice to know how to do the search algorithm, and it would be great to have more data. There are cost/benefits depending on how much data is to be sent by a QUIC connection. This depends on knowing more about how the Internet works. Gorry: This is the main reason the current draft does not define a search algorithm, it needs some data and some measurements. Chair: The TSVWG chairs will talk to QUIC chairs about the WGLC milestone for this draft to avoid causing problems. 5.3 Gorry Fairhurst (Proxy for Joe Touch): UDP Options draft-ietf-tsvwg-udp-options David: What is the time frame - will this be active after the next IETF? Gorry (as WG Chair): This draft is a normative dependency for DPLPMTUD as written. Is there a way we can ensure the does not cause delay? I think we can change the document to eliminate this dependency and allow the UDP Options draft to mature in its own time. David: The TSVWG chairs will talk to QUIC chairs about timing. Tom Herbert: I am concerned about distinguishing UDP options use of the surplus area from other non-standard uses of that area. Gorry (as presenter): Would requiring the checksum also protect this? Tom Herbert: Yes, but there is another issue with zero checksum. We really need a checksum, and would prefer a fixed header that contains it (current draft has checksum in a variable location). The checksum is needed for various reasons/ Tom: The idea of option negotiation is unclear in the draft, and needed for options that are not stateless. How do you deal with unknown options - startling TCP-style negotiated options and stateless mechanisms as in IUPv6. Gorry (as chair): I agree that clarity is important, please discuss on the list with Joe - the text needs to be clearer. Christian: UDP options should not be used with encrypted transports. Gorry: Note that the application is in charge. Chairs: There is a need to be clear on applicability statement. Gorry: I don’t know why a QUIC application would choose to do this? Christian: I assume that a UDP application using network path discovery will use packets of that size and set DF - you can’t use this. Gorry: Multiple levels of doing PMTU discovery is never good. Mirja Kuehlewind: This document is an extension to UDP and the use with QUIC is not something to discuss here. The QUIC WG gets to decide whether or not to use UDP options, that is a topic to be discussed in that WG if needed. Chairs: Please look at this draft and discuss on the list and with Joe. 6. New Work (if time permits) Individual Drafts for consideration by WG 6.1 Eric Kinnear: HTTP/2 as a Transport, in Transport Area draft-kinnear-httpbis-http2-transport This ID has been discussed in the httpbis WG. This is being brought to TSVWG for consideration of Transport concerns. It looks at a generic transport for bytes that traverse the Internet. It can also be a fallback when HTTP3/QUIC does not work on a path. How generic should this be? David Black (as individual): Please think about MTU - this is particularly when someone inevitably gateways this into UDP/IP. See the INTArea tunnels draft for how to think about this. Spencer (AD): Much more interesting protocol stacks are likely... You need to think about the worst that is possible in all of our collective imaginations. Eric: We will add text. Tommy: Where should this get worked on? Chairs: Transport issues need to be worked here, please continue to come back and ask questions. Chairs: We think would finally prefer a single draft, but could use a short draft to discuss transport here, if that helps to make progress and get things moving. There are also HTTP and INTArea issues - this is going to fit between all of these. You are welcome to bring transport issues here, please come and talk about these. Spencer (AD): This is an important cross-area activity, we will help. 6.2 Maksim Proshin: SCTP RTX bit draft-proshin-tsvwg-sctp-rtx-bit The authors currently have an implementation and plan to ask for WG adoption of a later revision. There was no time for discussion in the meeting. Gorry: It would be good to see performance results, analysis of the costs and benefits before a WG adoption call. Chairs: Please read & comment on list if interested in this topic.