THURSDAY, July 25, 2019, 1000-1200 Morning Session I, Laurier Chairs: Gorry Fairhurst; David Balck; Wes Eddy (remote). (Notetaker: Theresa Enghardt) 1. Agenda 2. Chairs Update: RFC's completed/in Queue: draft-ietf-tsvwg-le-phb (RFC) Document Shepherd: David draft-ietf-tsvwg-fecframe-ext (RFC-Ed) Document Shepherd: Wes draft-ietf-tsvwg-rlc-fec-scheme (RFC-Ed) Document Shepherd: Wes draft-ietf-tsvwg-tinymt32 (RFC-Ed) Document Shepherd: Wes Drafts beyond WGLC: draft-ietf-tsvwg-ecn-encap-guidelines (WGLC) Document Shepherd: David draft-ietf-tsvwg-rfc6040update-shim (WGLC) Document Shepherd: David (new text on fragmentation, review needed) Gorry: The text on tunnel remarking has changed in the latest version. Bob Briscoe: This text was written after WGLC responding to a WGLC comment. Gorry: It is unusual to have so much new text, we need to make sure we have review of this text by the WG. Markku Kojo: This is not the RFC3168 mechanism, I've sent comments to the list (about how to deal with fragment marking). Bob Briscoe: I plan to revise the text after the meeting. Chairs: Please make a new ID and we'll evaluate whether this is ready or needs another WGLC. (Slide 10: Related Drafts (2)) The overload protection ID is probably headed for independent submission to the ISE: Low latency DOCSIS Bob: We haven't spoken about this, but probably yes. This documents what is done in DOCSIS, rather than defining a new iETF mechanism. Gorry: Future work on this topic would likely fall within the WG remit. WG, please review this ID for technical clarity. Chairs: Milestone updates Chairs: Announcements and Heads-Up 2.1 Heads-Up Socks Proxy 6 (draft-olteanu-intarea-socks-6-00) Chairs: Has anyone read a recent version? (1 for previous version) Gorry: Please read and comment on list. Please consider this as a potential TSVWG work item. 3. Transport Protocols and Mechanisms Transport Encryption 3.1 Colin Perkins: Impact of Transport Header Encryption (WGLC) draft-ietf-tsvwg-transport-encrypt Tom Herbert: Is the latest version of draft is more positive to extension headers? I still think it's a little negative. We need to get better measurements of HBH options in the Internet, and find more recent data. Gorry: Please check current version. Tom: Deploying IPv6 HBH options is a known issue we're trying to resolve. There's lots of efforts to resolve it. At least suggest this approach could be used. Wording will be interesting. I'm not sure I've ever heard of intentional ossification. Colin: Protocol may make an explicit statement to declare features stable for all time, so you can assume they won't change. An example is QUIC invariants. Joel (Jaeggly?): When we bake something into an RFC we're kind of doing that. We are literally aiming for things to not change. Colin: There is a difference between this and a commitment to never change these bits. Joel: If you want to change the three-way handshake in TCP, good luck. Standardized doesn't mean it's not gonna change. Colin: Here, harm comes from a path preventing a change the specification in ways we want it to change. Tom: We now have two major transport protocols. One of the bits of QUIC was public, a middlebox vendor ossified it. Classical ossification we want to avoid. QUIC and TCP need equal consideration now. Colin: RTP is very widely deployed too, and did fix visible headers. Matt Matthis: In the past, there were drafts saying to enforce "must be 0" in headers and middleboxes checked this. That's ugly. Occasionally this creates attack vectors. Alissa Cooper: What about review from security area? Gorry: We discussed the SEC review last meeting. The security review was a long one, and really good. We went through comments and responded to each one, then updated the document. We added in text to address nearly all comments, and responded on mailing list why we didn't think some additional text would be helpful. I don't know if reviewer posted an update on whether they think it's fully addressed. Colin: I ad long discussion with Chris Wood - who was the reviewer. There was also an earlier review by Stephen Farrell. Alissa: Good to know. The document is not entirely unrelated to a previous doc, there is a chance that some language hits a series of people. Colin: We have presented it in OPSEC several times. Alissa: Some concerns could be dealt with while the document is still in the WG. That would make things easier. Get the feedback earlier. David: We plan to ask other areas during WGLC. Gorry: We welcome feedback. However, it is important that this ID documents, raises questions, but does not propose new solutions. Chairs: The next revision will go to WGLC, expected in August - if so, we will make this longer than the usual 2 weeks - because it will be in August. We will cross-announce to the OPS and SEC area. 3.2 Igor Lubashev : Loss Signaling for Encrypted Protocols (Individual) draft-ferrieuxhamchaoui-tsvwg-lossbits Aaron Falk: There is great interest to Quantum Internet Research Group that you use Q-Bits. Tom: What else is there, what other information? I'm worried if you give a mouse a cheese... Protocol-agnostic is better than protocol-specific mechanisms. How do we unify? Gorry: The current presentation is just one presentation in this space. There are other topics that are related, and they will all request bits to convey info. Martin Duke: If it's in QUIC header, of course it's authenticated. Not anyone can mess with those bits. Igor: We do mess with IP header bits, it's not going to be any different from what people can do right now. In the QUIC header it will be authenticated, there's advantages and disadvantages to any proposal. That's why we don't dive into details right now. We would like people to agree that this is a problem and we need to solve it. Martin: The threat model a serious problem when using measurement data that is authenticated? Igor: If a sender is playing fair and keeping a separate counter, I don't think it's an important threat model. Mauro Cociglio: I suggest to add a reference to RFC 8321 about ways to measure packet loss, use for case two different measurement points to understand packet loss Igor: We will definitely do more. This just uses one probe, one direction of traffic. Once you identify which direction a loss is, you could have another probe. ?: Can you compare with congestion exposure? There's some similarity. Chairs: Please continue to discuss this ID on the list. SCTP Drafts 3.3 Michael Tuexen: bis update two SCTP Spec. draft-ietf-tsvwg-rfc4960-bis Gorry: Have you looked at the ID with suggestions for a next generation SCTP (Individual draft)? Do you see anything taht needs to be in the bis document? Michael: We integrated almost all the errata in the base spec. Except for one document describing the I-Bit. The other suggested additional work is on changing concepts. I don't think anything applies here except the I-Bit. Gorry: If the WG thinks there are any other additions to this document, please come to the mic. This document is meant to be a stable specification for this protocol, and we don't want any last-minute proposals. When is next revision? Michael: Maybe tomorrow. Michael Tuexen: NAT for SCTP draft-ietf-tsvwg-natsupp 3.4 Maksim Proshin: Retransmit bit for SCTP DATA, I-DATA and SACK (Individual) draft-proshin-tsvwg-sctp-rtx-bit David: What is your intention for this draft? Maksim: I asked for adoption and I will update. David: See you in Singapore! Michael T: Do we need negotiation? What if a receiver does not understand? Maksim: You can mistakenly think that your first original send... yes, needs negotiation. Gorry: This looks like good plan, but what is the complexity? Chairs: Please continue to discuss this ID on the list. Transport Working Group Drafts 3.5 Gorry Fairhurst: Datagram PLPMTUD draft-ietf-tsvwg-datagram-plpmtud Gorry: The draft contains all the framework, and is stable. There are some topcis requiring research, and measurements - but these are not the purpose of the current draft. We think this ID is nearly ready to publish. Chairs: We expect a WGLC before next IETF. Removal of UDP the options text was an executive decision by the chairs in the hope to get this published before the UDP Options work is complete. Tom Herbert: Is there implementation? Gorry: There have been 4 implementations we know about. There is FreeBSD work in the git, this won't be upstreamed until spec is finished. There was another project in git. Another in the QUIC at hackathon into mozquic. Tom: Good to add a reference to it. Gorry: We will have this in shepherd writeup. Not sure if it is useful to add to the draft? Michael: We have implemetations on demo applications. We did an early implementation , but this has changed as the WG document finished. We hope to update the latest algorithm in our SCTP implementation. 3.6 Joe Touch (Presented by Gorry): UDP Options draft-ietf-tsvwg-udp-options David: A crucial text change is if the UDP checksum is not zero, you have to use the OCS. There may be a corner cases with tunnels, this needs to be worked out on the list. David: There has been proposal for a must-support flag in the option header, which indicates that no further options will be processed if this option cannot be parsed. Any objection? Tom: I expected discussion here? David: The chairs are looking for a sense of the room on the proposal. Matt: Does this allow rewriting packets? To drop headers without dropping packet? David: No, this is receiver behavior for an option that is not supported. The most you can do is to toss the option and later options. Mike Herd: Yes. Magnus Westerlund: I think that is the right way. Tom: I think it is more than ceasing option processing. Based on IPv6 HBH options. This bit in an IPv6 option type tells the receiver to skip an option not recognized or to drop the packet. Drop the packet if not recognized, because the rest of packet may be incorrect. This means you can't have options that modify the data. Two use cases for UDP options: A Trailer with a UDP payload, I agree. In node 2 (?) there's no legacy receiver. Payload in surplus we can do what we want with it. Gorry: Are you saying if anything is critical, a receiver should drop options? Tom: Drop the packet. That is the IPv6 way. David: We are retrofitting here to UDP, not disturbing the existing UDP payload. Tom: We already cannot deliver data that has not been properly processed. We cannot deliver fragments to applications. We need to be careful. David: When we use fragmentation, all of the fragment data is sitting in the UDP options area. Tom: There may be other cases where we cannot deliver that data. Encryption, compression? Gorry: Agree these could be done as options, but I do not yet see a new point. David: If there is UDP payload and a problem in options processing, then you can drop options, but can't drop the UDP payload. Tom: We may need this for extensibility. You want to make sure we can have version 2 and we can have this option in case. Mike Heard: The problem is that some options affect data handling, so data must share fate. What Tom said and we see it in the encryption case as well. Gorry: Let us make sure this level of agreement is actually on the list and that Joe is on the same page. David: Going forward we maybe could divide the option space for critical options. We'll figure this out on the list. Gorry: Do we need the LITE option independent of the FRAG option? If we remove that, it'll be simpler. Magnus suggested on list that UDP-Lite equivalence is not needed and I agree this raises more issues than it solves and is unlikely to be ever used. Gorry: David: If you're doing DNS fragmentation because DNSSEC, you got individual checksum, do you also need reassembly checksum. Shove it in the application? If application is doing its own, does not remove need for OCS, make sure packet goes through the path. Tom: Agree David: Focus on: Does this do something useful for DNS? Mike Heard: No LITE option trailer, it does bad things to legacy receivers. David: One more voice for not keeping lite. Tom: Log all stateful or stateless options. I prefer the IPv6 method. If I have both of these, I can use the same implementation as for HBH options. Mike: We already ACS option for reassembly checksum. Gorry: We should not be using a CRC-16 for this length of data, SCTP and other specs use a CRC32c. David: iSCSI also uses a CRC32c, it's easy to implement with modern CPUs. Mike: CRC-16 was agreed on the list some time ago, but I agree that this decision should be revisited. Chairs: We expect Joe to collect the inputs and produces a new revison of the ID. It will then become clearer what issues remain. 4. New Work 4.1 Aseem Choudhary: RTG area (Diffserv and Yang) draft-asechoud-rtgwg-qos-model draft-asechoud-rtgwg-qos-oper-model David: Nit: You cannot use ranges with DSCPs, only a list of codepoints. Gorry: Any other comments? Can anyone help? Please ask on list as well. Are you looking for adoption in routing area? Aseem: Yes. 4.2 Jerome Henry: QCI and Diffserv API (no slides) draft-henry-tsvwg-diffserv-to-qci Jerome: We are looking forward to feedback from the 3GPP liaison. This is meant to be informative text, the first step is to express the intentions of this text. We do not wish to impose anything. e.g., we provide the intention of mappings if people build a multipath system. Translate these one to the other. Martin Dolly (AT&T, 3GPP): The table referenced on QCI is an informative table. Each carrier uses DSCPs differently, QCI can be as well between different carriers. Moving forward to 5G, the table is ever changing. Moving target and informative. Any kind of MUST language referring to an informative table is probably ill-advised. In addition, this is most useful for private network deployments, but not for carriers who already know how to provision their networks. David: Let's get the new text. This is potentially useful for private networks as starting point. Chairs: We expect a new revision of the ID for people to discuss. 4.3 Greg White: Identifying and Handling Non-Queue Building Flows draft-white-tsvwg-nqb David: Please don't put a specific non-IANA-assigned DSCP into running code! Gorry: ... yet. Martin Dolly: Thank you for your help with this. Subir Das: Thanks for this draft. Softening that language helps. For the WiFi sections you have SHOULD, but for LTE you have MUST. Why? Greg: The reason is just editorial, depending on which of the co-authors wrote that. I don't think there will be a concern. Gorry: Obviously the WG would have to decide on the recommendations. Chris Lemmons: You have SHOULD for protection against mis-marked flows. Application that does not implement that are in a sorry state. If application can classify, why do we need DSCP? Greg: The reason this is a SHOULD, is that some queue disciplines do not need to implement this, like per-flow queue systems. Gorry: I suggest this needs more text. Subir: Security considerations is a good thing. Maybe this needs more elaboration on who is responsible for marking this. Chairs: Who has read? (12-15) Chairs: Can we have a hum if this topic is worth pursuing in the WG? YES: Strong hum NO: Silence Who supports adoption? YES:Strong Hum In doubt: Silence Magnus: There seems a very clear consensus that we can adopt this. Chairs: We agree. The Chairs will confirm this on the list. FRIDAY, July 26, 2019, 1220-1350 Afternoon Session I - Place du Canada (Notetaker: Michael Scharf) 5. Transport and Network - Chairs Wes/Gorry: Review of WG discussions preparing for WGLC of L4S drafts Chairs: The first item on the agenda will be a summary of the IPR discussion that has taken place on the list from the chairs' perspective. Disclaimer: Full version: The chairs are not lawyers. This is not legal advice. If you want legal advice, you need to talk to a lawyer. (No comments allowing the summarised IPR) 5.1 Bob Briscoe: L4S ECN drafts draft-ietf-tsvwg-ecn-l4s-id draft-ietf-tsvwg-l4s-arch draft-ietf-tsvwg-aqm-dualq-coupled Slide "Implementation status" Andrew McGregor: Are you aware of anybody who is working on putting L4S support into the Linux WiFi stack? Bob: I am not aware of anybody doing that. Do you volunteer? Andrew: Unfortunately I may have no time for that. Slide "Open issue #1: RFC3168 ECN in a FIFO" Jake Holland: Akamai has observed ECE codepoints in the wild in the Internet. Some production traffic has ECN enabled. Some servers indeed see some ECE marks. Rod: Help from operators to get data would be very valuable. Gorry (chair): Would this need a change to the 3 specs? Bob: Not to the spec, but I can update the text. Gorry: Sounds reasonable. Chairs present slide deck with potential discussion topics seen on the list. Jake Holland: I would like to add one item to the list: Admission control for untrusted markings in a classifier. Gorry: This is classified as useful research in RFC7567. What do you suggest? Work in the WG? Jake: That is an interesting question. I don't have an opinion right now. Christian Huitema: Evaluation of the L4S experiment. All slides compare L4S to CUBIC, which is not designed for low latency. I would like to see a comparison to a delay based CC, in particular BBRv2. Bob: We are waiting for BBRv2. Jonathan Morton: I have 4 topics: f) The Congestion Response/Marking Differences experiments enabled for in RFC8311, (with the effective redefinition of the CE codepoint proposed required an RFC with consensus. RFC8311 did not in itself give this approval. g) Incremental deployment requires compatibility, which has not been demonstrated so far. a) Effective congestion control is required. Codel is the most deployed AQM. With the current Codel, the time to reach the correct marked rate would be 4 seconds (?). 4 seconds for a link with 10ms is not effective. The inadequate response of DCTCP (and thus presumably Prague) to Codel is of only slightly less concern in FQ form, due to the consecutive-bottleneck problem alluded to in point B (where the upstream bottleneck may be a dumb FIFO). b) Fair queueing is fairly robust. My concern is when there are two consecutive bottlenecks. In our experiments we have found issues. Chairs: The latter sounds like an issue in FQ-Codel. Peter Heist: I highlight 2 topics: e). A strong concern against using ECT(1) as classifier. DSCP relies on domain security at domain borders. With ECT(1) there would be no borders. h) Implementation status. There are issues in the repo. TCP Prague is over-reacting in experiments. There will be further interopaibility testing. David Black (from floor): Regarding open issue #2. The whole point of the L4S experiment is an experiment for the Internet as a whole: this was much discussed before we adopted this work item. The interaction between queue can occur anywhere in the Internet. But, resequencing is different. For instance, for wireless links there can be asymmetry. But, this does not happen inside data centers. The underlying cause for resequencing delays does not exist there. The problem mostly occurs in specific access networks. It has to be solved there. It is not appropriate to mandate that all Internet end nodes be modified in order to take advantage of L4S. Gorry: We need clarity on what the intention is. Is this specifying recovery in terms of time - which could then lead to relaxation of sequencing requirements *or* is this specifying a relaxation now? The latter would need cross-area review before moving forward. Bob: It is the former. We are saying that a link has the capability of not doing resequencing packets with the identifier. David: This is proposed as Internet-wide experiment. I still believe that this has a major scope problem. Bob: The relaxation is only for ECT(1). There is an opportunity to use a time-based loss detection. It seems like a good opportunity. David: I see the opportunity for a separate experiment. Gorry: As chair, I concur with David that describing other features apart from the core requirements for the ECN experiment really needs to be put in a separate experiment. If we do that, we will have to go to Int Area and RAI. Bob: The document only says what the endpoint must do. It does not day anything about the node. Gorry: Does the annex needs to be there? Bob: No, the annex is not needed. Gorry: With QUIC and RACK being deployed, tolerance to reordering may improve anyway. David (from floor): You are running two experiments. Is the annex is normative? What if we pulled the annex into a separate, informative document without any normative reference from the L4S spec. Bob: The normative specification in the main part could be a SHOULD. Chgair: As chair, I would recommend removing the paragraphs from this document that lead-on from the experiment and those that pass comment on DSCP deployability, we think the current text requires additional cross-area review. Jake: This list is a list of technical considerations and I agree. In addition, I have raised on the list editorial considerations. There are significant editorial issues that I think must be addressed before moving the document forward. Gorry: What do you mean? Is this about the section order? Jake: This is about word choice, and ensuring it only makes technical claims. Gorry: This is excellent feedback. Please do send notes to the list. Jake: I sent a review of one section to the list. I am waiting for feedback. If I continue, it will be quite a bit of feedback. wanted to raise the issue about the wording. Please reduce the hype. Bob: I understand this comment. I have started, but not finished the reply - I think I know what to do and will revise. Chairs: Time for some hums... How many have read -architecture ID? (15-20) (+1 on jabber) How many have read -id ID? (15) (+1 on jabber) How many have read -dual-queue ID? (15-20) (+1 on jabber) Wes: Does anyone want to bring up IPR? Rod: There are people who want to speak to IPR are not present. Jonathan: Toke Hoiland-Jorgensen wants to speak to this later, he could not join. Chairs: Please read the IPR summary and decide on your own position. Chairs: Are these documents ready for evaluation in a WGLC? Please hum. ("yes": Weak hum, "no": Weak hum) (Jabber: +1 "no" from Dave) Magnus (AD): Some people think the current text is not ready. The text needs revised. People should have some few weeks to send technical comments to the list on what needs to be addressed. If you have technical concerns why it is not ready, please tell us. Chairs: This is a good idea, we plan to revisit this next month when a revised ID is available. 5.2 Bob Briscoe: Transport for L4S Data 6.New Work (if time permits) 6.1 Jonathan Morton: Some Congestion Experienced draft-heist-tsvwg-sce-one-and-two-flow-tests draft-morton-tsvwg-sce Related drafts: draft-grimes-tcpm-tcpsc Slide #7 Mirja Kuehlewind: For the CUBIC-only flow, what AQM is used at the bottleneck? Jonathan: Cake, i.e. FQ_Codel, with standard parameters Gorry (as individual): What is the pink plot? Is this with fair queueing? Jonathan: The two flows get separate queues. Slide #8 Gorry (as individual): Is this one FQ? Jonathan: This is single queue and there is convergence. Discussion: Gorry (from floor): Were the changes you mentioned upstreamed? No. Gorry (from floor): Please do post links to the patches. 6.2 Markus Ahmed: DCCP Extensions for Multipath Operation draft-amend-tsvwg-dccp-udp-header-conversion draft-amend-tsvwg-multipath-dccp draft-amend-tsvwg-multipath-framework-mpdccp The authors provided a short presentation after the meeting (see slides). There was no time to discuss this ID at the meeting, but they suggested the topic could be prioritised for the next meeting. Please read the drafts and do discuss this topic on the list. 6.3 Other items - please contact the Chairs None.