DRAFT Meeting Minutes for TSVWG Meeting at IETF 96, Berlin WG Chairs: Gorry Fairhurst and David Black TSVWG Session I 15:50-17:20 Wednesday Afternoon session II (Charlottenburg II/III) Note Taker: Stuart Cheshire Jabber Scribe: Mikael Abrahamsson -- ** Chairs gave status updates See draft-ietf-tsvwg-circuit-breaker (RFC-Ed, waiting for document) draft-ietf-tsvwg-rtcweb-qos (Approved) draft-ietf-tsvwg-gre-in-udp-encap (with AD) The GRE-in-UDP draft is now in IETF Last Call. The GUE UDP encapsulation draft is moving out of NVO3 and will be taken up by a new WG. -- ** David Black - DiffServ interconnection classes and practice Gorry: This document has completed WGLC. Please tell us if there are any new comments (none). -- ** Gorry Fairhurst / Lars Eggert - UDP Usage Guidelines draft-ietf-tsvwg-rfc5405bis (new rev after IETF-LC) Lars Eggert presented, and would like to see this published. See David: The document has been through IETF-LC. We made progress in TCPM this week. Pasi: The references to RTO-consider draft is only informative, this should not cause the process to stall. I don’t see technical issues blocking publishing the UDP-Guidelines. David Black (shepherd): I recommend to publish as-is (with updated text in RFC5405bis, and a pointer to draft-ietf-tcpm-rto-consider for more guidance). A decision will be made in August. -- ** Colin Perkins - Discussion of what ECN Circuit Breakers mean for RTP draft-ietf-avtcore-rtp-circuit-breakers See The specification of an ECN circuit breaker has been removed from RTP Circuit Breaker draft, because requiring a single ECN CE mark to be treated essentially the same as a *single* dropped packet would be inappropriate on networks where ECN CE marks are generated much more frequently than the equivalent packet drops would occur. RTP feedback and adaptation is typically aggregated with timing determined by the media (e.g., adapting after one or more video frames - that can be several RTTs for a low a RTT). Matt Mathis: Some of the marking schemes that have been proposed mark at high rates, this means that signalling is being delivered to the protocol that created ECN. It may be that at some future time that a circuit-breaker can be defined that triggers. I would add a place holder to future mechanisms. Colin: That is true. Matt: The work needs to be done before the circuit breaker for RTP is defined. Bob Briscoe: I feel this conversation is not based on any code or experience Gorry: The Fast-Trip circuit breaker is designed as a time-out for congestion control. Bob: The point of a circuit breaker is not to protect your flow, it is to protect the rest of the network from your flow. Colin: My point is that driving the queue to overload can be problematic to other users. David: If you see significant marking, you may have made congestion mistakes. Bob: Yes, you our someone else with whom you share. RFC3168 says if you see too much marking, you should turn-off ECN and deal with the resulting loss. Christian Huitema: The point of ECN is to trigger rate adaptation and keep queues small. ECN is a signal of queues, loss is a signal of problems. Matt Mathis: As originally seen ECN-CE was equivalent to loss. This is not true any more, 50% marking can be observed int some cases: ECN-CE marks may be frequent an d do not signify a problem, and hence should not trip a circuit breaker. You can not know what a CE-mark means. Matt: New AQM ECN algorithms are marking differently, and generally the way to set CE-marks does not matter. Dave Täht: I agree. I have seen networks with a high rate of ECN-CE marks, which is now normal operation and not a problem. I think a combination of drop and mark is clear sign of a problem. Koen De Schepper: The sender decides what kind of feedback it wants, in the future if you set ECT(0) means marking is equivalent to drop and, a new meaning for ECT(1) may be defined. Colin Perkins: We have been told that ECT(0) marks are not to be treated as equivalent to drop for a circuit Breaker. John Leslie: Delay may be a better indication of a problem. Chairs: Please discuss this on the list. It would be good to present guidance to RMCAT who also building ECN methods for RTP. — ** Michael Welzl - TCP Alternative Backoff with ECN (ABE) draft-khademi-tsvwg-ecn-response (Adoption requested) This partially replaces draft-khademi-alternativebackoff-ecn) See The aim is to allow experimentation with an update reaction to CE. The document was updated to try to make it address feedback we have received this week. Magnus Westerlund: How strong is the recommendation for apps to use ECT(0) in RFC 3819? David Black (as individual): There is a mild recommendation towards using ECT(0) We need a procedural draft that removes the limitations preventing experiments. Magnus Westerlund: We should strengthen the requirement in the new document to use ECT(0). Bob Briscoe: To preform an IETF-sanctioned experiment, we will write an Internet Draft. Michael: The -01 version of the draft seeks to describe this. Gorry Fairhurst: The draft that we wrote is not intending to create a free-for-all. The point is to enable future IETF experiments by publications of RFCs. Colin: RFC6679 says that ECT(0) is to be used by default, ECT(1) can be negotiated, as can random marking. Michael: We should say this update applies to RFC6679 Koen De Schepper: Can we assume the network performs marking an ECT(0) packet as exactly equivalent to dropping a non-ECT packet? David Black : The network behaviour is the same for ECT(0), but one of the proposed changes is in the reaction to seeing a CE-mark. David Black: Three experiments are taking place. One is decoupling ECT(0) from ECT(1). The other is treating the response to a CE marking as different to the response to drop. Colin Perkins: It seems like CoDEL and PIE already mark CE differently to a droptail router. Michael: There is no exact equivalence, when ECN is used packets are queued differently. Matt: Agree, but that’s not a problem. David Black: It may also be time to declare the ECN-Nonce experiment has failed, and hence RFC3540 may be classified as Historic. Bob Briscoe: This draft is just about enabling the experiments, not what we do after those experiments are over. Stuart Cheshire: Current seeds of iOS and macOS use ECN for 50% of TCP connections. Currently no connectivity problems have been reported. David Dolson: You still have to treat CE-marking the same as drop. ??? Michael Welzl: We have a document in TCPM that shows the benefits of changing the sender reaction and shows that treating CE more mildly than drop can be a little unfair, but not nearly as unfair as you might imagine. Bob: I was going to submit a draft like this, and think we need to do proceed with something like this. Dave: If there is a shaper/policer it can either marl or drop. These need to be equivalent, to prevent unfairness. Michael: The reaction is different to loss (see TCPM this week). There can be unfairness, but not significantly more to worry about. Dave: So this impacts devices that police etc in the network? Michael: The assumption is that the network does the same, mark or drop would be the same for a router - it is the sender reaction that changes. David: We will on Friday do a sense of the room on whether to adopt the -01 version of this draft. -- ** Bob Briscoe - Identifying Modified ECN Semantics for Ultra-Low Queuing Delay draft-briscoe-tsvwg-ecn-l4s-id (Individual draft) See Matt Mathis: The current square root property in TCP is a bug, and shouldn't be perpetuated. There is no need to be backwards compatible with it. Bob Briscoe: It is important to do no harm to the existing Internet. Christian Huitema: I agree the square root element is a bug. You should find some other way to balance the marking between the two queues. Not everything today uses the square root formula. CUBIC does not follow the square root formula at higher rates. Compound TCP (in Windows) also does not follow the square root formula. Bob: It does at low rates? Christian: This isn’t so. Bob: We need to choose something. Mirja: Given there was a lot of positive feedback on L4S when is this document to be discussed? Gorry: We will return to the adoption call of the PS update on Friday. -- ** Vincent Roca - Forward Error Correction (FEC) Framework version 2 draft-roca-tsvwg-fecframev2 (Individual draft) See Gorry Fairhurst: Is there any interest in work on this topic? (About five people raised their hands.) WG Chairs: Please continue this work and use the TSVWG list to discuss the draft. *********************************************************************************** TSVWG Session II Note Taker: Randal Stewart Status and agenda were reviewed. Tom Herbert could not be at the meeting, so no slides were presented. ** David Black: Short discussion on: TCP Alternative Backoff with ECN draft-khademi-tsvwg-ecn-response The draft has porposed 3 changes to enable 3 Experimental RFCs to proceed. Aaron Falk: All three drafts need to make it clear that sending packets can conflict with other drafts. Christian: Experimental stars is fine. How will we know that this experiment is complete? Chairs: The experiments are to determine if the protocols are deployable and safe for Internet use. We expect a request to publish as PS once experience is gained. David: draft-khademi is proposed as one ID to create a singe Standards Track that modifies RFC 3168. Spencer Dawkins (AD): I am good with everything, but what is meant by "experimental or better RFC" in the slides? Gorry: The draft says the updates need to be EXP or PS. Chair: No objections to proceed. David Black: I expect to write a draft with some editors that addresses this update! --- ** Fred Baker -- DSCP mapping to 802.11 draft-tsvwg-ieee-802-11 A draft may have a normative reference to an informational document. This forms a down-ref. If you believe that there is significant dependencies, then you can normatively refer to an Informational document. Dave Taht: I have two issues: - There are other diffserv code points — but others said no - In one part the document describes CS1 as Background and Scavanger -- which is meant? Andrew Macgregor: The term “background” at L2 is the same as “scavanger” at L3. Fred Baker: Someone wants a whole new Scavanger class, this guy wants that if the queue is not 0, or higher than a thresh, we would drop the packet. I am not recommending that. Fred: What is being done to make sure 802.11 is aware of the document? Pat Thaler: I think 802.11 should be informed about this. The chairs will send am email to IEEE noting this document is being prepared for publication. Pat: I will also inform the 802.11 -- Donald Eastlake volunteers to note this next week at the 802.11 meeting. Chairs: Should the present draft be a PS? Fred: Do we want the document to be published on the Standards track instead of an Informational RFC? Chairs: We will send an email to the list. Mirja: Why would this be a PS? What are the reasons this should be PS? Fred: This document sets codepoints that implementors should follow. Mirja: That sounds good. Michael: If a PS encourages people to comply with this, that would be a good thing. I think this should be PS. Reedier: Should we fix the Scavenger Class (i.e., which DSCP is recommended)? David Black: There is no PS document that says CS1 is to be used for Scavenger. Fred: CS1 was chosen because Internet2 was already doing this, rather than because of a PS. Chairs: David will be the document shepherd. We will send email proposing that this document will be requested for publication as a Proposed Standard, if no objections the document status will be changed. (Note: A PS request requires a higher level of review.) --- ** Bob Briscoe - Guidelines for adding Congestion Notification draft-ietf-tswg-ecn-encap-guidelines-07 Bob Presents slides and speaks to recent outcomes (two). Chairs: David Black will send a liasion statement back to 3GPP (it is in his outbox). --- ** draft-briscoe-tsvwg-rfc6040bis Bob would like that tunneling drafts reference this new bis document (6040) Bob describes his changes since the last meeting. Chair: Gorry to have a look at Bob's guidelines update. The chairs requested reviewers from the WG. These included: Randal Stewart Randal Jessup Chairs to issue a WGLC against the updated document. Bob had produced a second document by extracting tunnel recommendations from the Working Group document. This was being requested to progress as a PS. Mirja: The documents you plan to update often do not speak of ECN - so there is no text that needs to be updated. Bob: No - the issue is that next time the tunnel spec is used, they need to read the text. Michael: Is the text generic enough that the exact text is OK to implement. David: No you describes issues with incompatible ingress and egress? Bob: Yes. Chairs: How many people have read the draft? (few). Chairs: Not enough people have yet read to currently adopt 6040bis in room. We will ask the question on list. Aaron: Are there implementations? Bob: There are IPsec implementations, but I do not know of reported measurements over tunnels. Mirja: I am still not sure if Update is the correct label, but then it identifies missing text. This is on the borderline. Gorry: I think you should supply text that actually says what to do for each protocol that you say this updates. David: Bob please add "updates" boilerplate and create sections for each update and insert small section that specifies the addition/update to be applied to each RFC. Spencer (as AD): I do not know that you have to state each RFC update in a separate section, but I know that smart authors do. --- ** Michael Tuexen - SCTP Stream Schedulers draft-ietf-tsvwg-sctp-ndata Michael presents his slides Chairs: The Chairs are looking forward to starting a WG last call, authors declare -07 is now ready. Chairs: Would people volunteer to read the code, read the document? Randal Stewart: I will read the code and the document at the same time and check. Dave Taht: Is there a Linux implementation? Michael: I believe there is work on this (Marcello). Jabber: Randell Jesep will read. Chairs: We will read and start last call as soon as possible. --- ** Michael Tuexen - RFC 4960 Errata and Issues draft-tuexen-tsvwg-rfc4960-errata Status -- Noted interest in adoption last meeting, but no adoption call was run on the list. Is there still interest in the WG? (Hum for, none against). Chairs: Gorry will arrange an adoption call on the list, after reviewing a diff' document for SCTP. --- ** Michael Tuexen — SCTP NAT Chairs: When will this be ready for WG Last Call? The author says the NAT draft will be ready for the Seoul IETF, and include IPv6 examples. No questions. --- ** Michael Tuexen - Additional Considerations for UDP Encaps of SCTP draft-tuexen-tsvwg-sctp-udp-encaps-cons Spencer Dawkins: The proposed .bis draft would be a complete replacement? Michael: yes. --- ** Gorry Presents for Joe Touch -- Transport Options for UDP draft-touch-tsvwg-udp-options Joe asks if the WG would be willing to adopt this as a PS or EXP. Christian: What is the proposal of hiding the application layer data? Answer: The after the UDP length is data options data not application data. Christian: Hide a bit of a mis-nomer. Mirja: You can send to a receiver that has not been updated - this is a deployment story. Spencer Dawkins: The PLUS BoF was yesterday, and we may have the same discussion here. Gorry: An important point is that this data is intended to be used for the transport. Stuart Cheshire: Its not hide from application, it is with the current API the apps do not get to see it. Lorenzo: It is data that could be passed as a CMESG. As an App you can send this data at the end of the packet. Gorry: The stack can use the network as a part of it processing. Lorenzo: Does the draft say that the network should not touch this data. Mirja: It makes me sad if we have to say this. It is transport. Christian: Is it OK for an App to drop packets that have this type of payload. I will drop any packets that behave this way. Mirja: It is not implemented this way. Christian: I think this is a side channel that is unsecure and uncontrolled. I think these packets should be dropped. Stuart Cheshire: I see the PLUS BOF that is about how you use the data, I see this as about where it is. David That: Is there anyone working on a newer API? Gorry: TAPS is a forum to develop new standards and this is a great place to submit drafts about APIs. Lorenzo: Is there a case to allow the network to insert data into a packet? … No that is not what we are talking about. Lorenzo: What would you use this for? Gorry: (Speaking as self) Examples could perhaps be Timestamps/PMTU-Discovery padding for this. DCCP has this sort of feature, but UDP does not have these features. Lorenzo: If the stack changes things (or in the network) then why can you not just add new headers. Rewriting the packet header is a problem. Michael: An unprivileged process can not write these options. David: The existing socket api would not see this data in the read call. Tim Shepard: The use-case needs to be clearer. The draft could use a bit more for motivation Chairs: Discussion should continue on the list. Chairs: The path forward is that this is not yet ready to run adoption call based on this discussion. It would be good to understand more about what this is good for and look at that version of the document. Author may want to take input from the PLUS BoF. Lorenzo: I would worry about any options that can be used by an operator to signal cookies out of band. I argue that a covert channel is scarery. Please send comments to the list!! —- ** Roland Bless - A Lower Effort Per-Hop Behavior (LE PHB) draft-bless-tsvwg-le-phb RFC2470 doesn’t really say whether the CS1 is to be treated correctly, and motivates choosing a per hob behaviour that has a dedicated DSCP that means LE. This would update RFC 4994. Fred: Why do you say the DS draft placed CS1 above CS0. David: The class selector defines an order. Fred: Is this local use? - what type? Roland: This would be a PS (standards action). Ruediger: I prefer the first three bits to be consistently used - I prefer a new code point rather than CS1. This is an issue that needs to be settled. David That: I think an unambiguous DSCP is good. David Blake: The CS class was a transition mechanism. Brian Carpenter: (form DS chair). I think the draft is the right thing to do. I think it is time to do it properly in the 000 class. This seems spot-on. Chairs: How many folks have read this ID? (at least 6 people) Chairs: How many people would like to see adoption? (Humm for, few against). The sense of the room is to adopt this draft. Chairs: Ask for a draft 01 to be prepared and we will then ask on the list whether the WG is ready to adopt as working group draft. Fred: Does this change hold other documents? David: The 802 draft needs thought about how to handle this - we plan for the document to be published, and then this new work on Scavenger class will later update this. Andrew: Would it be good to reassign CS1 to UP2? ******************End TSVWG****************************************** The following notes were taken on the AQM discussion within the TSVWG Session II at the Berlin IETF. ** AQM chairs need followup on status of PIE conflict between Informational and Experimental, which is it ?? ** Recharter?? New work: -- Slides from Wes. Bob Briscoe -- is there something we can do to socialize AQM?? -- A new document advertising it?? Fred: We have a draft that was targeting experimental status, and we have push back from the IESGs that we need to describe the experiment. Mirja: We talked, you just need to add text. Fred: We’ll publish as Informational (Codel is Informational in the Draft header) Gorry: Mirja (as AD) will follow-up with the WG Chairs. Bob: Is there a chance for a short document that says something about what AQM solves? Gorry: A little like the ECN benefits draft? Roland Bless: Operators were reluctutant due to parameter problems, and sometimes feared to loose utilisation. The three AQM's have different properties as to loss (from experiments) -- maybe this is a good subject of a draft/paper? Christian: We just had a discussion about what is the experiment? -- a experiment report would be very useful on what happened after AQM was deployed? Michael Abrams: Operator talking to other people: People don't know about buffer bloat and there is a lot of folks that need convincing -- We still have a lot of stuff to do in the operational aspect (5 years more work to do). Fault finding and monitoring is important also. Michael Weltzl: Some algorithms have thresholds (PIE for example) -- The sections talk about future work should include that this threshold should be evaluated as we proceed to proposed standard. Koen: Sometimes having large buffers is *good* with existing networks -- and if you cut down on size of buffers you impact existing applications. Operators are very concerned about existing customer experience. Having config small AQM may have a big impact. There is a blocking case that brings compromise. We need more evaluation, and to understand customer experience. Bob: This is about writing up experiments on the existing AQM’s. Gorry: Is it research lab experience or deployment? Koen: We have lab experience that informs customers of what the impact is. Aaron Falk: +1 to having a experimental experience report -- IAB may be able to help bring operators and others together (based on report). Dave Taht: I strongly agree with the need for more research -- could this be in ICCRG? -- As to operators its an outreach to nanog or the BBforum -- ongoing work in AQM -- bring this work back into TSVWG is to get wider coverage would like to see the AQM WG closed. Fred Baker: Cable Labs specified use of PIE for DOCSIS. Andrew: There is other work about doing AQM in the lower layers, that is baking that might be relevant to here when ready in a year or so. ** Does anyone want to do algorithm twiddling? Dave Taht: No, get current algorithms deployed. Michael Wetzl: Presentation on research on new methods always welcome in ICCRG. Bob Briscoe: It is important to also consider attacks against any AQM. ** ?? -- FQ-Codel solves a lot of these problems in the network. Fred Baker: FQ-PIE -- has had two proposals, but it does not matter how you drop. Christian: Should there be the same relation between next AQM and ICCRG as the same as the security world, where we do research in a security research group and then if they get ready to come in then they bring them into the security world. So maybe ICCRG should be place for new algorithms. Andrew MacGregor: Plus 1 on that -- AQM goes idle until ICCRG explores new algorithms. Michael Weltzl: ICCRG used to be very busy.. but there is space on the agenda for AQM. ** New congestion control algorithms in general should go first for discussion at ICCRG.