TSVWG met in two sessions at IETF-98 (Chicago) Chairs: G Fairhurst, D Black, W Eddy Note takers: V Rocca (Session 1), M Welzl (Session 2) Session 1 1. Agenda (WG Chairs) Wesley Eddy has joined as a 3rd co-chair. 2. Status/updates (WG Chairs) 2.1. Documents with Chairs - 4 RFCs published since IETF 97. - 2 IDs in RFC Editor queue, waiting for a missed-reference. - 3 drafts completed WGLC and need author action: - Tunnel Congestion Feedback - David to work with authors - Stream Schedulers and User Message Interleaving for SCTP (discussed later) - Gorry to work with authors - DiffServ to IEEE 802.11 Mapping (WiFi) - David and Fred Baker have work to do on issues raised against the draft - this is likely to need a second WGLC - 1 ID to go to WGLC soon: ECN experimentation - 5 other active WG drafts 2.2 Charter & Milestones - See slide for WG Milestones details: https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessa-1-agenda-and-wg-chairs-slides-00.pdf - 3 IDs calling for WG Adoption: - L4S (Low latency, low loss, scalable throughput Internet service. - discussions hold so far suggest probably adopted. - See presentation on Thursday. 3. WG Drafts 3.1. Explicit Congestion Notification (ECN) Experimentation draft-ietf-tsvwg-ecn-experimentation David presented on behalf of authors. The current version includes comments received during adoption and David believes is basically ready. Gorry asked who read it: 6 people. The proposal is to have the current version go to WGLC. Mirja believes the document should say "we do this because it's the right thing to do, and that it also opens up experiment space", rather than "we do this because we want to do this experiment". This comment is not about the content, but about the wording. So next revision, incorporating Mirja's comments, will go to WGLC. 3.2. A Lower Effort Per-Hop Behavior (LE PHB) draft-ietf-tsvwg-le-phb Gorry presented on behalf of Roland Bless. Many updates have been made from revision -00 to -01 based on WG feedback (see the slides for details). There are two different semantics to LE, however current suggestion is to only use 1 DSCP. There are also DSCP marking issues with domains applying old marking. A quick review of David Black comments is made, including concerns about the use of "MUST" on deployed running code. A review of comments from Rudiger Geib, in particular the suggestion to add text on the way ECN and LE should interact. WG opinion would be useful. Concerning the choice of which DSCP to use for LE, there are 2 proposals: DSCP 4 and DSCP 2. The use of DSCP 2 presents advantages, both should not be bleached if upper bits are cleared. But there are problems too, as other DSCPs, when bleached, could get remarked to DSCP 2, MAPRG data shows this is happening. Also MAPRG data shows that a bit more than 10% of the time, DSCP 2 might be bleached to all zeros which is sufficiently frequent to pay attention to. Is there another possibility? Matt Mathis proposes to assume that DSCP 2 is the right answer and then inventory the amount of harm that will happen. A question is asked: is there a specification about passive open looping back the marking (i.e., can the server echo the code back so that one knows that it survived)? This seems to be out-of-scope for everyone, but would be of benefit, and we need to start somewhere. Matt is not just talking about TCP. Mirja reminds that ICMP gives what you want for looping back the DSCP, even if ICMP does not work all the time. David Black agrees with Matt about moving forward with DSCP 2. Gorry (as not a chair) suggests looking at codepoint 5, and his MAPRG presentation this week will explain why it is working well. Gorry explains he may have more measurement data for the Prague meeting. David suggests to delay decision till September, in the hope to have more data till then. 3.3. Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines Presentation by John Kaippallimalil. This document has been around for a while, and a new version has just been posted this morning. This draft got positive responses from IEEE and 3GPP. John then reviews how comments received have been addressed. A suggestion is made about issuing a WGLC for this ID as well as draft-ietf-trill-ecn-support that depends on it. David agrees as they are for the same class of mechanisms in different contexts. Gorry highlights that this ID hasn't really been changing and if anybody volunteers to do an early review, we could do that before going to WGLC on both. Donald Eastlake and Ingemar Johansson volunteered to do an early review. Bob clarifies that the TRILL draft depending on this is approaching WGLC too. TSVWG chairs will talk to TRILL chairs and try to get both into WGLC. 3.4. Propagating ECN Across IP Tunnel Headers Separated by a Shim draft-ietf-tsvwg-rfc6040update-shim No presentation requested. Bob Brisco explains he does not have much to say. He did not manage to update this, and plans to do that by May 2017. TSVWG Meeting at IETF 98, Chicago, USA WG Chairs: Gorry Fairhurst, David Black and Wes Eddy Note Taker 1: Wes Eddy Note Taker 2: M Welzl Jabber Scribe 1: Magnus Westerlund Session 2 Presentation by Gorry: TCPM WG: Retransmission Timeout Requirements draft-ietf-tcpm-rto-consider Gorry: Note that this will be WGLC'ed here, it applies to other transport protocols, not just TCP Presentations by Felix Weinrank: Stream Schedulers and User Message Interleaving for SCTP draft-ietf-tsvwg-sctp-ndata Felix: A clarification on weight, double weight = double capacity. Gorry: This is past WGLC. We believe all issues raised have been addressed. Will check with Michael if this is updated, will issue a new version and proceed to shepherd writeup. Last chance to comment. SCTP Network Address Translation Support draft-ietf-tsvwg-natsupp Felix: This is ID is not related to WebRTC Gorry: The feedback matches things on todo list, we expect authors to address and submit a final version. RFC 4960 Errata and Issues draft-ietf-tsvwg-rfc4960-errata Felix: There were no changes since last IETF. Gorry: This is the first round of expected changes which will update the base spec. It is an important document. The procedure is to try to capture everything before opening an update to the main Spec. Please read and comment if you see any issues. Additional Considerations for UDP Encapsulation of SCTP (5 minutes) draft-tuexen-tsvwg-sctp-udp-encaps-cons Felix: There were no changes since last IETF. Gorry: We previously requested feedback on this; we went through issues, preferred update to the doc instead of list of changes. That is what we asked for and that is what we expect. 6. Individual drafts Presentations by Joe Touch (remote): Transport Options for UDP - Gorry Fairhurst for Joe Touch (10 minutes) draft-touch-tsvwg-udp-options Chairs: How many people had read the draft?: 8 Tom Herbert: The bottom line will be, is this practical for Internet? Joe: Legacy UDP will just throw away the option data. UDP stack would interpret that data. Tom: UDP length not included, right? Joe: UDP length is shorter than the IP length, we did not need anything extra from IP, IP thinks it is an IP payload Tom: There will be problems, e.g. UDP encapsulation... TSO... devices are not going to handle that. Joe: Everything we have tested allows the information to go through when it is a relay, and an endpoint simply ignores it if it is a legacy endpoint, this is exactly what should happen. It is possible that an endpoint could just truncate the information, but if it does we will figure this out with the checksum, user will not have a problem. Christian Huitema: I am concerned that putting data in this gap will allow putting supercookies in packets and stuff like that. If we start having a logic in which we expect this place to be used, we allow attackers to use it. This is outside the TLS security envelope, I would like to drop the packet. Gorry: This is the same for all transport protocol options. Joe: If you drop packets that would be a violation of spec. If you want to send supercookies there are a thousand other ways. Christian: Not with something like QUIC, for example Lars Eggert: As chair of QUIC, is there any benefit for QUIC of having this option? If this would make something like QUIC work better that would be a powerful deployment reason. Else maybe not so useful? Joe: We are not doing anything that an app layer can’t do. The problem is, getting every app layer to do this cleanly is hard. If it is transport all apps get it. E.g. frag/reassembly, if we could rely on UDP to do that there's one less thing apps have to do. Bob Briscoe (remote): (answering Christian): Maybe this is an opportunity to secure this space. Just because a spec says this is now legal does not mean attackers are not already using it. Christian: Yes, correct. My preferred solution is we drop any packet that has anything in this grey area. Gorry: That would be against IETF guidance. Christian: App options are inside security envelope, this grey area is not. The fact that it is not protected by the encryption envelope that gives me jitters. Bob: We could specify it within the encryption envelope. There is an opportunity here to do this. Joe: I like this suggestion. I disagree that this is not part of the security envelope, security envelope for IPSec would cover it. This is in the same place as any kind of option space; at some point when you do next layer up you have to take this into account. If you want to protect this you have to have header protection security or IPSec. TCP options are not covered by TLS. Show of hands: interested in progressing something in this space: 5 + 1 from jabber people who think we shouldn't: 1 Wes (chair): Assuming we address the security problem, would that make it better? Christian: If the options are included in the TLS security envelope I would have no problem. IPSec isn not used (much) in practice. Joe: Why are you not concerned that TLS does not cover TCP options? Christian: I am, that is why we are doing QUIC. Gorry (chair): The WG will ask for clarity on how security problem should be treated; then do an adoption call; we will later cover question of intended status and which options will be included. Joe: AOK. Presentations by Vincent Rocca: Vincent Rocca - FEC Framework Extension to Convolutional Codes draft-roca-tsvwg-fecframev2 (10 minutes) Vincent Rocca - Random Linear Codes (RLC) FEC Scheme for FECFRAME draft-roca-tsvwg-rlc-fec-scheme (10 minutes) David Black: Any 3GPP interest in this extension? David Moses: For high speed links such codes are a must in the physical layer. So why do we need this? Vincent: having it at an upper layer makes sense anyway even if there is protection at the lower layer. This is one of the conclusions of the WG. David Black: A concatenation of links on a path can create problems. Georg Mayer, (3GPP liaison): I can't find this draft on the dependency list which we have to find which drafts should be pushed. About video, this is something that is on the 3GPP agenda with a high priority. I am not sure how this draft will fulfil the requirements that we set but dependency by referencing the draft in 3GPP specs. This does not have to be a WG draft but of course if its is it will make it easier to convince people. Vincent: Both drafts exist, and can easily be mentioned in the 3GPP proposal, no problem. Gorry: This is a change of framework to include methods known for decades. If we open it for that my concern is this could open it for a succession of other FEC schemes, etc - do you see this as the start of a family of drafts or is one proposal enough to make a real contribution? Vincent: This proposal is clearly the main solution. It will not fit all use cases, since this is limited by coding complexity. It may not be a good solution for doing the same with large encoding blocks. I do not expect to come back again to TSVWG soon. For the moment, for the current use cases, this is a solution. Matt Mathis: If I miss too many frames to repair a hole, I could potentially need to retransmit a single frame, this could later help repair earlier frames, is the in the spec? Vincent: No. I could be done if you are in time but there are probably other ways to do that. Lars: This needs expertise in this space. The more you put on the plate, the more concerned I am if we have the energy and expertise for it. Vincent: We could also say this is a good opportunity to bring expertise in this domain. Let IETF make efficient tools in this space, which is not the case today. David: Again, error protection should be at the link layer. Vincent: Packet FEC is included in 3GPP specs for end to end, we have these schemes in the standard, you need it e2e too. Gorry: We do not need to discuss the FEC frame architecture. This is already something we have in the IETF. Chairs: Who has read the ID? 5 hands. Brandon Williams: We would appreciate having a standard thing as opposed to the stuff we are doing now. Interested in seeing this go forward. Chairs: Who think this is interesting to work on? 12 hands. David Black: What is time frame for clarifying the 3GPP situation? I understand it is been proposed to 3GPP but not yet picked-up. Georg: When something is on the dependency list it is highlighted, for example FEC scheme is on that list. When a company comes and wants it and there is consensus to adopt it, it can be listed. Dependency could be ready within the next 2-3 months so we could highlight it officially. David B: Is this decision likely to be at a next major meeting? Georg: This depends on companies to bring it in. I can not say at the moment, we do not think in those terms. David B: Let is assume that Vincent and his colleagues will bring it there and time frame is a couple of months. Adoption call will happen on the list in future. Chairs: people who think we should adopt this, just as a question: approx 10 Chairs: Who thinks we should not adopt these drafts and do this work? 0 David B: We need at least one person who is not part of this work and can check if this is the right code. David B: Do you have reviewers for the maths part? Vincent: Yes I can find these. Presentations by Koen De Schepper - L4S: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture draft-briscoe-tsvwg-l4s-arch DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput draft-briscoe-tsvwg-aqm-dualq-coupled Identifying Modified ECN Semantics for Ultra-Low Queuing Delay draft-briscoe-tsvwg-ecn-l4s-id Slide L4S Deployment Sequences: Gorry (as individual): The DCTCP ID was specified only for not-Internet usage. Koen: Yes, walled garden. Use in a controlled environment. David Black (as individual): If we have one bottleneck that uses Dual Queue, everything may be wonderful. When there are two bottlenecks in a row using Dual Q, interesting things happen because CE marks from the low latency queue go through the wrong queue in second bottleneck. WE need to find if this is a real problem. Bob Briscoe: You do get multiple bottlenecks sometimes, but it is rare. This was mentioned in TCPM. The marked packet also gets into the low-latency queue in the second bottleneck, so the packet will be delivered earlier. David B: One of the reasons for running the wide area experiment is to look at how often these things appear in practice and how to deal with them. Koen: If marked, the packet gets in the low latency queue, so it gets faster response to congestion. It gets priority, so it gets in the L4S queue, this is also a potential benefit for classic TCP, plus there is congestion, so there is no issue with repordering. Wes (Chair): At the last meeting there was energy, on the list too. We think we should adopt, so we need to think about milestones. David B (individual author): We would like to get the ECN Experimentation draft off to ADs next month. Have not seen major objections. I have reason to believe that this will be revised and through WGLC by end of April / early May. Mirja Kuehlewind: Nods in agreement with timeframe. Bob: to David: need to define what classic ECN should do with ECT(1), we are going to write this out on the list. David Dolson: Whether this works depends on whether devices can be configured David Black: The challenge is to open space to run the experiment. The draft is reasonably clear on ECT(1). If it does not encompass what to do if you are not part of the experiment it is close. We will look at the text. Gorry (individual): we do not seem to have a specified transport that would allow for Internet experimentation using L4S. We have the TCP-Prague proposal, but currently nothing on the experimental track that defines how to use the experiment. Koen: We have to have at least one working implementation, we do not know if we need a draft. Congestion control, I guess this has to be ready before we can experiment on the Internet, right? Gorry: Yes, I think we need a spec, or a list of requirements. Mirja: What does the arch. draft say that you should use as congestion control? Koen: Anything that behaves more or less like DCTCP. It does not say if negotiation is required. Mirja: Accurate ECN will have negotiation. Does this block us here from moving on? David Black (as chair): I wonder if a fudge is possible where we have spec for DCTCP and just state somewhere that this could be used for this experiment? Gorry: I would strongly protest. DCTCP said explicitly there are issues that need to be addressed to deploy outside the data centre. Let's be careful as we go forward. Mirja: We should check the draft. It should say "only use it in an environment where everyone is using this kind of stuff". Not necessarily controlled environment. L4S is a new service, we can expect everyone in this experiment is doing the same kind of thing. Gorry: Any non-L4S routers on the path are the issue. Koen: But what if the transport is backward compatible with drop? Bob: The spec says that DCTCP can be used in controlled experiment, I would agree with Mirja that this is a controlled area across the Internet. Respond to drop but also fall back to Reno-like behavior. DCTCP does that. Getting to the point where we have code and spec. Maybe we need to check some more what controlled environment means. Gorry: I will look at drafts again to check my understanding of this. Mirja: A personal comment, I think this is good work and we should enable experimentation here. Congestion control is part of the experiment and we're going to look at it. Spencer Dawkins: I am excited about the possibilities after the ECN experimentation draft. Phil Eardley: This is good stuff. Can we do it without a working implementation of TCP Prague? Gorry (Chair): . I think we have raised this, and people will look.We are now in danger of ratholing: we all know accurate ECN is cool. Christian Huitema: I am not worried about routers that don not do ECN. There you will get loss signals that tell you something. I am worried about routers that do ECN the old way, there are a few of those. This will be interesting if you found a way to detect specifically that - how often did I try something and I believe I found a legacy ECN router on the path. Koen: Other experiments are also going on, Apple have enabled ECN, they can say how much traffic is marked. Christian: Yes, but this is specifically about the ECT(1) codepoint. Adoption call: Chairs: Please show hands for those who have read the drafts: 12 Chairs: Does anyone think one of the 3 drafts is immature, or would like to consider these individually? - No one. Hum if you think IETF should adopt work: clear hum. Hum if you have concerns or think we should delay work: silence. Chairs: There is a clear consensus to progress these drafts. We will take this decision to the mailing list to confirm this adoption call. Mirja: It would be good to add an experimentation section with guidance on how to run the experiment - things like: don't enable it for all traffic, what metrics to measure, etc. Presentation by Ingemar Johansson High ACK rates for transports operating at high speed Tom Herbert: One of the side effects of generic receiver offload is stretch ACKs, it does happen in real life Praveen Balasubramanian: Stretch ACKs are pretty common, Windows stack has been doing that for a long time, a sender should be able to know when that's happening Mirja: True, work is ongoing for TCP, that is good - but for QUIC there is nothing defined, I think we cannot discuss this at the moment for QUIC. Gorry: There is a related BCP already (BCP69), RFC339 - let’s just talk more and take Mirja's comments into consideration. Qiaobing Xie: This is good work, we must make sure that SACK is covered in the study, SACK is generated by a different set of rules. The meeting closed.