Minutes for TSVWG Meeting at IETF 93, Prague, CZ -- Session 1 Wednesday 22-07-2015 -- WG Chairs: Gorry Fairhurst and David Black Note Taker 1 Karen Nielsen Status/updates (WG Chairs): The chairs are looking for a third wg chair (or secretary). Please come forward if you are interested in taking this position. James Polk, former third tsvwg co-chair, passed away recently. The wg observed a minute of silence in the memory of James. See http://www.arkko.com/tools/allstats/jamespolk.html for James's contributions to the IETF over many years. Work Status: Additional Policies for the PR Extension of SCTP has been published as RFC 7496. Recommendations for Transport Port Number Use (RFC-Ed), draft-ietf-tsvwg-port-use, is in auth48. It is anticipated to come out early next week DTLS Encapsulation of SCTP Packets (RFC-Ed), draft-ietf-tsvwg-sctp-dtls-encaps, is at rfc editor waiting for another draft (MISSREF). SCTP Quick Failover is anticipated very soon to go to the IESG, but we will have a presentation about that here. 3 other IDs are likely to go soon to WGLC. 6 remaining WG IDs. 2 RSVP IDs were edited by James Polk, if any people are willing to take over, please come forward, otherwise it is likely that they will not be finished. Milestones: The WG should expect to see some Milestone updates coming between now and IETF 94 in Japan. The August milestones to be stretched – WG will move them to the end of the year. Present end of year milestones to be put later. Agenda: There were no comments to the agenda. Announcements: Jana announced the QUIC barbof Wednesday night saying that QUIC is a new transport protocol that Google have been working on. Bob Briscoe announced the RITE demo for the dual queue AQM at Thursdays Bit-s-bites. Relates to the AQM session presentation on AQM that separates DCTCP from non-ECN TCP. WG Draft Presentations UDP Usage Guidelines draft-ietf-tsvwg-rfc5405bis Presented by Gorry Fairhurst. Changes have been applied recently in this document. Hope to be nearly there for WGLC. Significant contributions and review comments have come from Magnus Westerlund. A section on ECN has been added. This describes how to use ECN over UDP. Mirja Kûhlewind helped with the ECN text. New text added about RTT implications of Congestion Control, that needs the eyes of the WG. Routing documents will reference this document for how to use UDP encapsulation. The document applies not just to applications but for anything over the internet that uses UDP encapsulation. SCTP/TCP react directly after detection of congestion. UDP rarely does. UDP applications can take much more than one RTT to react – that is don’t react immediately to congestion report and may take a while to report that congestion has been seen. Previously not be talked about in the document. New text added to this effect for prompt reaction to congestion signal. Actual design may differ. RTP is particularly treated. Comments requested. Discussion: Bob Briscoe: suggest for 2 stages. Feedback should always be prompt. Reaction does not need to be prompt, unless the congestion situation is bad, requiring reduction. Gorry: UDP apps don’t always want feedback to be prompt Bob Briscoe: But the reaction should not always be prompt. Gorry: If you have ideas, please help with the text. Bob Briscoe: okay. Mirja Kuehlewind: I am not sure about the formulations, I think it SHOULD say will reduce. Kevin Fall: "competes fairly with" - need reference. Typically one would also describe the circumstances to qualify fairness. Gorry: We don't want to be overly prescriptive, this text was in the original RFC, I am not sure anything has changed. Michael Ramalho: words will be hard to come by. Can help working on that. It will take at least a roundtrip and many applications will not declare congestion right away. It is going to be bounded by a roundtrip time, but beyond that we need to work on the language. Gorry Fairhurst: The text actually says 2 RTT: 1 RTT for detection and 1 RTT for reaction. Michael: between one and two – can make good words, but not easy Colin Perkins: I think I understand what you are trying to say. It seems that there is a push to make behaviours look like TCP. I am not sure that we necessarily want that. We want to respond to congestion. We do want applications to react to congestion, but this seems a little too prescriptive. I think I have a slightly woolier set of prescriptions in mind. Gorry: It doesn't need to be the same as TCP, but does need to respond. I Wrote text to get started and to see what people thought. Mirja Kuehlewind: Suggest "must not starve competing traffic" for the last paragraph. I don't like the word fair. Everybody has own definition of fair. Should speak about the aggressiveness. Gorry Fairhurst: Don't want to use the term aggressiveness. The original sentence has been in the doc for a long time. Further the sentence appears multiple times in the document. Please suggest a good sentence. Mirja Kuehlewind: In the rmcat groups we worked on the wording on requirements for congestion control. There are the rmcat requirements to look at. Detect congestion is also very vague. Lucy Yong: Will this apply to multicast? Gorry Fairhurst: I suspect so - Greg as co-author will be able to answer. Bob Briscoe: A flow doesn't know whether it starves another flow, but it can calculate its congestion rate I personally think these considerations will be better in the circuit breaker document. Gorry Fairhurst: We need to talk on the list, afraid we can not do this design here. Need to bear in mind that often UDP feedback is very limited so we cannot write a specific formula. David Black: ... essentially this is what the last sentence is saying. Bob Briscoe: I said compare it with an arithmetic number. Need to explain on this list. Matt Mathis: This is the tip of a very deep problem. How can we say less. The important point is to decompose what congestion and collapse means. Know of two phenomena that contributes to collapse - must not respond with increased load. Back pressure and congestion needs to have a reasonable scale. It is nice that the scale is on similar magnitude as TCP, but the problem is that people turns this into TCP fairness. Gorry: This text needs to raise the problem, not give the answer Matt Mathis: A UDP app can do congestion collapse with just with dns. Lars Eggert: This is a BCP-bis on which there was consensus a couple of years ago. That's why there is only a few MUST in there. This is one part of a pretty long section on what kind of reaction to do. People need to read the section and come back with what they think. Keep in mind that we are giving guidelines. The goal is to have text that routing area or application developers can understand. Need to be pretty high level Gorry: This document is not aimed at readers in the TSV area. Christian Huitema: doubt about sending rate for UDP application. Perhaps ok for voice. Another case of congestion collapse with UDP - Lost connectivity on the network, routers reboots, everyone goes to the dns on the same time. Lars: This also is in the doc. Christian Huitema: Many apps have no concept of a sending rate. Lars: This is discussed also in another section. Mirja Kuehlewind: I have a different proposal: should say UDP shall implement CC, if you don't know what you're doing, then do cubic. Gorry: I agree, it already says so. Gorry: The ECN text has some MUST and SHOULD statements. These are intended to be consistent with the AQM ECN benefits document, but are the first time the rules have been written down for UDP. Mirja has sanity checked that document. At least 2 have read. People please check. David Black: I wonder about the 4 MUST statements. Gorry: I'll check, I think one of these could be rephrased. Gorry: There is also a summary list at the end of the recommendations. Things to be done for 04: zero checksum MPLS/UDP, mention tunnel draft. Lars Eggert; jabber: draft-byrne-opsec-udp-advisory-00: Cameron Byrne wrote a document about UDP attacks. If you are using UDP, you need to be aware that you may be blocked. If this draft is going somewhere one should refer to it here. Gorry: I will add some text to the security section on rate limiting. Colin Perkins: It should say something about consent/security. Gorry: I think it should - please provide text Lucy Yong: does this also mention usage of UDP source port. Concerns with UDP source ports. Gorry: Depends on what you want to say... David Black: use random source ports . Gorry: it mentions it explicitly for of path attacks and the use of ECMP. Chairs: Please use the mailing list. Once we are done with -04, we think we are ready for WGLC. ++ Generic UDP Encapsulation for IP Tunneling draft-ietf-tsvwg-gre-in-UDP-encap Lucy Yong presented GRE in UDP can go places where GRE can’t. Makes scenario not equivalent with GRE when using UDP. Concerns have been raised about this use of GRE in UDP where original GRE cannot be used. This has been a WG draft for a while. But now concern. No consensus yet. Would like to propose some discussion questions - hope to mitigate concerns How to have acceptable wording. Another concern is the status: Informational or Standards Track. Right now it is standards track. Several drafts are being published as informational (actually via independent submission editor), so can this be used Gorry: We cannot publish an informational spec because GRE as it is being maintained by TSVWG. Lucy: but this is GRE UDP. David Black: can withdraw from wg and try as individual. Would not recommend, when the WG has chartered this. Lucy: Leave options outside now. Martin Stiemerling: as AD: If submitted as an individual submission outside the WG, it would come to the IESG for at least ISE conflict review - there it would need to be reviewed and likely would be blocked as it's modifying an IETF protocol. Bob Briscoe: Middle set of bullet: What is the reason this text is there - is it because of problems with CC or other reason? Lucy: cc is one thing, but application may impact other application. Bob Briscoe: if this is all about CC, say if you encapsulating, if you are not determining the rate. Only forwarding. David Black: comes from MPLS over UDP. There it is solved by deployment in a traffic engineered network. GRE in UDP gets used in many places. Gorry: The issue is leakage of checksum, not CC. Magnus Westerlund: from a CC point of view - top bullet: biggest issue is around if it works in the generic case through the middle boxes. Handshake protocol would detect the black holes, but the is no handshake in GRE. Lars Eggert: restricting the ether type may help CC. Gorry: I personally do not have a problem with copying the CC guidelines from a similar document. However my question is does the WG want to specify for only a specific set of ether types - I would prefer to say safe for IP and need measures if not known to be congestion controlled. Lars: yes For IP we can assume the Congestoin Control is done by end-points. Gorry: If we only support IP, we would be writing a spec on a small fraction of what GRE can do. Then it is implemented and may be used in many other places where it is safe - e.g. Layer 2 tunnels Kevin Fall: We could cut these use cases away Lucy: Yes we would cut use cases away. Kevin Fall: We will need to justify why to cut the use case away. Lucy: The current application (ECMP) is in well-defined service provider network. Gorry: we have a maturing doc, but we still have a question on the scope and what we originally chartered. Anybody interested in making this generic, rather than only for ECMP?. If people are willing, then we can provide guidance. If we don't have volunteers, then there may not be enough interest to complete this. Please volunteer here and on list Bob Briscoe: I am not a volunteer. I am not sure the issue is more people. Do the authors understand what the problem is? Lucy: We don't know the solution. Gorry: This needs to not be constrained to one deployment and usage scenario. David Black: we need to be sure now is what this draft is going to solve. Conclusion (chairs): Chairs will work out what scope is useful. Volunteers to help define the text. [See session 2 minutes for follow-up on this topic - there will be two applicability scopes.] ++ Network Transport Circuit Breakers draft-ietf-tsvwg-circuit-breaker Gorry presented as an editor This doc should not include algorithms but should point to other documents. Next step: The guidance here seems mature, with other details needed in the related RTP circuit breaker draft. Please provide feedback. David Black: draft from pwe3 WG on TDM pseudo wires likely to reappear, recommends a managed (human in the loop) circuit breaker Gorry: It seems there is nothing more to be done in this draft typo fixing. Do not think that we need the other documents to complete in order to start a WGLC. David Black. I would like to provide a window for the pseudo wire draft to resurface. Gorry: OK, How long do we need to wait? David black: If it does not re-appear before the end of August, we go ahead and start a WGLC. SCTP WG Drafts : RFC 4960 Errata and Issues draft-tuexen-tsvwg-rfc4960-errata-00 Michael Tuexen presents: We have 5 erratas in the RFC data base. Also reports via email about a couple of errors. This is thought a good time to collect and document. Started a doc documenting all issues. Plan is when all errors have been documents then we make an informational RFC. This process was done in the past when going from rfc2960 to rfc4960. Karen: Is this draft only for errata or can it also contain changes? Gorry: We also should look at corrections, look at minor updates, look at what is deployed, we should be careful with how we handle this list as we start update work. If we do only minor changes it can be full standard. We need to keep in mind the standard status of the document. Matt Mathis: How is the errata status of the document - could we not just capture the errata that the RFC Editor already has? This seems like a choice of whether to write an internet draft versus updating a database. Randy Stewart: One change, the host name address parameter, is beyond an errata - we want to take that out. Chairs: Can we please hum for support doing maintenance on the base sctp spec: [hear some hums] Chairs: Who thinks this is not a good idea - i.e., we should only keep tracking errata?: [no hums] I hear consensus to do some work. Chairs: We will speak to the ADs about best approach to take this on. ++ Stream Schedulers and User Message Interleaving for SCTP (idata) draft-ietf-tsvwg-sctp-ndata Michael Tuexen presented. He presented key changes in between this and the last: text missing on the api perspective of author: text is complete in terms on content. some comments received: need a figure to clarify some of the operation - will be coming in the next revision. We also need some text for relation to stream reset. Except for this, people please read and provide comments. Gorry: How many have read ? 2 hands plus the authors. Chairs: Please continue to provide comments on the list ++ Quick Failover Algorithm in SCTP draft-ietf-tsvwg-sctp-failover Karen Nielsen presents on behalf of the authors Changes done in accordance with consensus at last IETF. Introduction completely rewritten. Security Section extended. A few other things. Two issues to discuss: Gorry has commented that it is unfortunate that the document introduced the Potentially Failed (PF) mechanism and the Permanent Failover is also a mechanism iwith the same PF acronym. This is acceptable, but is something to reconsider. Other thing is that the feature is SCTP Quick Failover "QF" but it is abbreviated SCTP "PF" as it is known under this name and is based on the Potentially Failed (PF) state. Want to bring this up here to make sure the wg agrees. Chairs; good points, does the WG agree with these abbreviations? No objections. Chairs: Now that it has been brought up, it should not be an issue! Chairs: Thanks for doing the update. A short WGLC will start now with closure in in two weeks. Gorry's comments on the naming of Permanent Failover shall be considered as input for that. ++ SCTP Network Address Translation Support draft-ietf-tsvwg-natsupp Michael Tuexen: describes SCTP support for IPv4 NAT. The purpose here is to see the presentation and then decide how and whether to move forward. Question raised on the list by George Wes: do we need this at all ?, IPv6 is coming. Michael we don't want to waste cycles on this if it is not needed. Magnus Westerlund: I suppose that you will need it, SCTP us is growing and IPv4 isn't going away yet. David Black: is this needed for rtcweb? Answer: no, that uses SCTP/UDP. George Wes: We could just talk about address translation. It would be more appropriate to write this as ipv6/iipv4 translation. David Black: Would it be reasonable if draft contained a number of examples including some with IPv4 and IPv6 translation? George Wes: yes that would be better and generic. Randy Stewart: The amount of IPv6 traffic is so small that it is noise, at some time is will be big, but until then we have to live with IPv4 problems. George Wes: IPv4 is not going there for a while, but I do not think with new features Chairs: This document has been on-going for a long time. It is needed to make SCTP become more deployable. We confirm it is still in our charter to do this. ++ Additional Draft (last-minute agenda addition) Christian Grothoff - TCP Stealth draft-kirsch-ietf-tcp-stealth Chairs (on process): This is being presented here because it is about ports and TCP. It was discussed on the tcpm and tcpinc list. We don't know which wg this work will be done in, but the discussion will be resumed here. Pasi (tcpm chair): why is this draft being presented here in tsvwg? Gorry: The ADs invited the presentation here. The purpose is to see the presentation and then decide how and whether to move forward. Christian Grothoff presents: Port scan, infection, command and control, your data becomes their data. ORB detection hacks your machine and uses your machine to break into others. TCP stealth : two possible solutions: minimal invasive hotfix, which this is. Stealth uses the sequence number to put in some crypto, but from the outside it will still look like a normal handshake Protect the first payload coming from the client to the server. Not compatible with nat. Implemented in the kernel. Does not require fiddling with config files. Suggested as mature from years of community feedback. This is a well know vulnerability that we can fix. We need a standard to make this work. Comments: David Black: Security work usually requires crypto agility. How do you negotiate the HASH for this? Christian: We don't. We don't need a strong crypto for this. David Black: Do you actually need MD5? Advise to make sure that you do not rely on crypto capability of MD5. Christian: The space also is limited. Gorry: Why don't you reference Fernando Gont's draft on random initial sequence number selection. Do you think this is different from the security approach in there? Christian: We behave differently afterwards Tim Shephard: One needs to address this - I want this code. I think you need to explain why it is ok to start with the same sequence number again. Christian: You can change your shared secret. Tim Shephard: You Need to explain better in the draft. Need to explain why the limitations of the draft is ok. David Black: Also you need to explain why you don't need a nonce. [Off-line follow-up - David is not convinced that not using a nonce is acceptable.] Christian Huitema: I want to see this problem solved. However, I am very skeptical about the solution. You have a replay attack. I can replay a pre-existing connection. TIP S: he is only trying to solve the port scanning problem. Christian Huitema: The attacker can monitor your link. So they can see the port you can use- This mitigates against active port scanning, but I am not convinced that your design does protect against passive port scanning. I think you should have a vpn solution. Christian : vpn is not a good solution. This is the same as with the existing TCP AUTH option. TIP S/Christian: TCP AUTH may not get through. Richard S: I believe that it is useful. The reply attack should be addressed. There are ways to address this (discussion). More of this discussion in the paper. Spencer Dawkins, as AD: Martin and I have put our heads together. This is not in the scope of tcpm. At least not now. We need to talk about this on the mailing list. We will continue the conversation here (tsvwg) for now. Finish the conversation we started here. Let more people read the draft and figure out what they care about and where then to go. Gorry: this has been dormant, it has expired. Christian: It will be revived. We will have an open discussion. Gorry: This work will may move elsewhere if we will work on it. I will ensure existing TCPM comments will be forwarded to the list. Christian H: Recommends review by security area as soon as possible. Chairs. We are aware of this. This will not progress before there is a security person supporting this. Please look at slides and draft and send comments. END OF 1st meeting session. -- Session 2 Thursday 23-07-2015 -- WG Chairs: Gorry Fairhurst and David Black Note Taker 2 Szilveszter Nadas Related activity: Simplemux: a Generic Multiplexing Protocol (draft-saldana-tsvwg-simplemux) traffic optimization was discussed in the IRTF GAIA RG session on Wednesday and will be taken up in a Bar BOF this (Thursday) evening. 6.1 Chairs - Guidelines for adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines Liaison sent to 3GPP (David apologizes for delay, as prior liaison to IEEE was sent some number of months ago. Bob Briscoe: is there anyone here who knows incompatible 3GPP spec? Magnus Westerlund: will have a look. Bob: important that when Apple uses ECN, they check potential problems with this ECN interaction 6.2 David Black (on behalf of authors) - DSCP and other packet markings for RTCWeb QoS draft-ietf-tsvwg-rtcweb-qos (Draft to map application API priorities and Data Types to DSCP) Changes proposed to DSCPs used for data channel. Harald Alvestrand: SCTP stream scheduling prio is important when the network is not helping you. If you put flows to different SCTP associations then if the network is not helping you, then you might have trouble. ?? Justin Uberti: Proposal - pick the DSCP that corresponds to the highest application priority, use that for the SCTP association, then use the stream scheduler to figure out the rest. Fred Baker: Uneducated regulators and transport groups. Is it priority in the network or what? David: 1. Priority comes through app interface from app to browser. 2. Browser picks DSCP and sends that to the network 3. In the SCTP association where streams are muxed there is a stream scheduler, that may be driven by a priority not visible to the network. David: Simplification - for each AF class, we will use only one drop precedence for Web RTC data. Cullen Jennings: 2 things: 1. For a given SCTP association, need a knob to set DSCP. 2. Within a single SCTP association with multiple streams, how are those ordered? We need to think which of the 2 want we exposed. rtcweb WG should work this out. Tim Shepherd: why not single SCTP with many DSCP David: Congestion Control in SCTP affects all streams. Reordering is bad for that, see draft-ietf-dart-dscp-rtp (at RFC Editor). Karen Nielsen: That could be fixed, but WebRTC would like to take SCTP as it is today. Gorry: we do not have experience of mixing DSCPs on single SCTP association. Karen: The SCTP change would be to define a Congestion Control context per DSCP, based on the SCTP multipath design - that requires work. We could have started that. This was discussed after the DART meeting in Toronto (1 year ago) and the requirement went away. Ruediger Geib (DT): Need wait and see what is gonna be deployed. 10 DSCPs for a single 5 tuple seems unlikely to be preserved by a carrier/ISP network. Justin Uberti: what should WebRTC know about consequences of changing DSCP? A (several SCTP people - Karen Nielsen, Randy Stewart): Reset congestion control. David: Should be easy to do for WebRTC, as the SCTP implementation is in the browser. Gorry: let's make a note that it shall not be reused without understanding for other work Ruediger Geib: We might want to say something about which DSCPs can be used by a browser. D: what the network does can obviously depend on network policies Harald: we started with looking for a way to tell the network what to do. The best way we found is DSCP bits (these are wiped anyway by default) Bob B: there is a demonstration that we can do all prioritization in the end-system. D: There was no objection in reducing the number of data DSCP. relayed from Jabber: It sounds like Justin's proposal would work for implementing the "set to highest of any DataChannel in WebRTC", and reset the congestion control if needed at the point where the DSCP changes. Is there a reason not to do this? D: no problem with that, let's see the discussion in rtcweb. [follow up note: On Friday, the rtcweb WG agreed with Justin's proposal.] 6.3 Ruediger Geib - DiffServ interconnection classes and practice (20 minutes) draft-ietf-tsvwg-diffserv-intercon Rudiger Geib presenting No questions. Gorry: How many people have read the draft? 6. Please, would those who have read the draft review and comment on the list. 6.4 Tim Szigeti - Mapping to 802.11e draft-szigeti-tsvwg-ieee-802-11e Collecting information on what is out there, providing guidnace on mapping, not bringing any new QoS to the table. Dropping network control packets (CS6 and CS7) only applies when sending to end-user, not to wireless links that are part of the infrastructure. Cullen Jennings: the approach to collect only what is in the RFCs may be dangerous wrt "running code". Fred Baker: it is fair to say that a not used DSCP is to be dropped or remarked. Make it go away. Anycast service includes host to router communication. That may be a problem for dropping network control traffic. Rather not say anything about that in the spec. Cullen: if we implement this video mapping web browser guys will put all elastic video traffic on these high priority classes Tim S: I can do changes after revisiting RFC4594 Andrew McGregor: the consequence is that if any neighbor with a higher class gets to send (i.e., obtains the transmission medium) first. Tim S: BG vs. BE: the different is 4 slots only Andrew McGregor: the difference is that the probability of being able to send might be an order of magnitude lower. CS1 is OK here. BE UP0 might be needed for coexistence with bleached traffic? David B: CS2 is used in gaming as better than BE, which is not used here Fred: could the gaming community tell us that? Fred: Video should not be more than a specified/fixed percentage of the load. Andrew McGregor: the current default mapping is BE UP0. Even if that should not be like that. Rudiger Geib: please have a look at the rtcweb-qos draft it will become interesting Gorry: We need to think about more than what the RFC says. Tim S: Our exercise is using the RFC only, not saying opinions. Gorry: tell something about the contention problem when 1 AP bleaches other not. Tim S: are you telling to map AF1 to UP0 Fred prefers to map all AFs to BE access category, not sure in video. Cullen Jennings: Gaming Counterstrike uses EF Mikael Abrahamsson: Word of Warcraft game traffic ended up being marked for voice QoS on our network, so we started bleaching that to CS0. Andrew: we have a few Gigs of gaming conference trace Fred to chairs: RFC 4594, we should talk about revising that Action to Tim: Look into gaming traffic and then send email to the list Gorry: Action item to Tim to look into mapping of AF1 class and send email to list Tim: this mapping applies in many places including wireless drives in phones. Mikael Abrahamsson: Can we have this table transmitted from the AP to the devices? So admins could change this. Tim: that standard is coming. This draft provides information until then. MA: is that coming standard general enough? Action to Tim: send pointer to that forthcoming standard to the list, and cite that (under development) standard the draft Tim Shepard: despite gathering what is out there it seems that you have to make decisions. Is this really appropriate for an Informational RFC. If you want to deploy it to devices then it shall be mandatory. AP configuring looks a good alternative. WebRTC might conflict with this. Tim Sz: The underlying RFC (4594) is informational, so this document that depends on it cannot be proposed standard. Gorry: This mapping looks informational. OTOH, RFC 4594's informational status seems problematic. It was published as informational because the TSV chairs felt that there wasn't enough deployment experience. Perhaps the time has come to produce a proposed standard 4594bis. Gorry: Are the IEEE folks familiar with this work? TS: yes I am working with some members, no official presentation yet. There are examples in 802.11 - two tables that are inconsistent with many implementations that I know of. Those are very bad to work from, but they are the only thing that exists. TS: Goal is WG adoption of this draft. 6 people have read this draft. Action to all: if you are interested in this, send something to the list. It is also time to send different proposals. David: thank you for all the hard work on this 6.5 draft-wei-tsvwg-tunnel-congestion-feedback (Xingpeng Wei) Tunnel Congestion Feedback + WG Adoption request Bob B: we are sending this count/feedback info in the packet in order to reduce state at tunnel egress. David B: Brian (Trammell), have you talked to IPFIX community about this? Brian Trammell: Advice read RFC7031 on how to register with IANA, these items appear reasonable to send to IANA. Bob B: this draft is pointing to use cases. Bob B: this uses IPFIX, because that has some reliability 3-4 people read this draft. How many would be willing to read and review? Around 4. Gorry: hum who thinks that this is useful to work in tsvwg. Not an adoption call. Pro hum: many Con hum: silence. Mirja Kuehlewind: informational, or experimental? Gorry: we do not have to decide now. Mirja: this looks like a concept which does not require standardization. Maybe informational status is sufficient Brian: you do not even need a draft for an IANA codepoint. Explanations going to registry shall be enough. Lars Eggert: experimental looks ok, I would not be happy with proposed standard. Mirja: no congestion response content in draft. Gorry: intent is to add that later. Mirja: Are there response mechansism defined? David: mechanism can be decided by the reference. At least one #3 Congestion Management (response) action would have to defined in order to publish this draft as an RFC Mirja: this could be informational, I would like to see the congestion management (response) emchanism, before deciding. Gorry: call for adoption, target: informational, we might make it experimental later on, we need deployment for that. Call for informational doc adaption Pro hum: many Con hum: silence. Will adopt as informational. David: to be confirmed on the list. ++ GRE over UDP update Offline discussion has yielded a path forward - write two different sets of applicability text: (1) Network operator usage. This could use GRE in full generality and omit UDP checksum for IPv6 if/as appropriate, text can be extensively based on RFC 7510 (MPLS/UDP). (2) General Internet usage. This would be restricted - traffic SHOULD be congestion controlled/responsive, UDP checksum for IPv6 would be REQUIRED. -- 6.6 David Black - Discussion of Scavenger Class support in DiffServ (30 minutes) Underlying question: CS1 is currently the recommended DSCP for Lower Effort (aka Scavenger, aka Less-than-Best-Effort) PHB/service. Should it be replaced with something in the 000xx0 range, e.g., 000010 ? Bob B: Why does 000010 remove the risk of priority inversion? David B: That DSCP is currently unused, most likely bleached. If not then 3 most significant bits are 000 -> BE. I define prio inversion as giving low prio better forwardign treatment than BE gets via CS0. Bob: Needs to be standardized at the right time, but not sure when that would be. Mikael Abrahamsson: 000010 arose from a discussion about what is incrementally deployable, as CS1 is ineffective for operators (will most likely be bleached to CS0). Andrew McGregor: it is still necessary to recommend to use congestion control. Gorry: Agrees. Mikael Abrahamsson: in my experience, 95% of ISPs just bleach CS1 to CS0. I would like to address this. ISP not supporting LE (at new DSCP) would have to understand that traffic is tob be carried as Best Effort if LE (Scavenger) class not supported, but preference is to have worse fowarding behavior than Best Effort. Cullen Jewnnings: can we change Scavenger? There is history for that. Look at statistics and analytics about the CS1 codepoint. Very hard to respect what is deployed e.g. Bittorrent vs. Linksys. Bob B: Clarification: this has to have a Best Effort response if bleached. Example 2 flows 1 filling the link, the other is scavenger - it should be using what is not used. If it gets promoted both get half the link. David: LEDBAT in this case can help. Bob B: never going to fly. You cannot interconnect this. The way to do this is arrangement with the network. You are wasting codepoint trying to do this. David: not sure. Bob B: if it is by arrangement then no need for reserving. It has to be by arrangement only ever. Mikael A: arrangement is common practice. Gorry (summarizing): there is interest, interconnect is an issue. In order to move forward, we would need to have a draft that is acceptable to the WG membership. Does anyone want to volunteer to write it - if so, please asy so on the mailing list.