TSVWG, IETF-89, London Meeting 1 1520-1620 Wednesday Afternoon WG Chairs present: Gorry Fairhurst James Polk David Black david.black@emc.com Note Taker: Karen Nielsen Jabber: None. Connectivity Problems. 1) Chairs: NOTE WELL Document Status and Accomplishments 1 RFC, RFC7141 Byte and Packet Congestion Notification has been published since IETF 88. 0 RFCs in RFC queue 0 at IESG 2 ID in WCLC: DTLS Encap of SCTP for RTCWEB and RSVP for PCN IDs thought almost ready for WGLC: SCTP NAT: draft-ietf-tsvwg-natsupp SCTP Path Failover: draft-ietf-tsvwg-sctp-failover-03 RSVP Application-ID Profiles: draft-ietf-tsvwg-rsvp-app-id-vv-profiles-01, (MMUSIC dependency for WGLC). 7 IDs being worked upon. 1 ID called for WG adoption: ECN encapsulation (WG adoption to be decided on Friday) Status of Milestones: Milestones were revised at the last IETF. Newly revised milestones for January 2014 were not met. WG needs to regain credibility in this area. 2.1) WG ACTION * Georgios - RSVP for PCN (5) draft-ietf-tsvwg-rsvp-pcn-08.txt Presenter: Georgios Karagiannis. Two main changes have been resolved following comments from IETF88. The first addresses that fact the proposed solution was not well matched to the PCN model (PCN decision point moved from ingress node to egress node). Second, e2e RSVP reservations are no longer subject to admission control simplifying a number of issues compared with RFC4860. All issues are believed to have been addressed. There were no questions or comments. The next step is to go into another WGLC. A two week WGLC was issued starting at this IETF. 3) Draft Documents related to RTCWEB 3.1) Working Group Drafts * Michael - DTLS Encap of SCTP for RTCWEB draft-ietf-tsvwg-sctp-dtls-encaps-03 Presenter: Michael Tuexen. It has been a long time since the WG last call started. A couple of comments have been received and the changes will be applied. These include: - Some textual clarifications will be made. - Some text from rtcweb user drafts will be moved into this draft as the text is not specific to rtcweb usage of SCTP over DTLS, but generic for any usage of SCTP over DTLS. - It is required for PLPMTUD to (MUST) be done either at DTLS or SCTP layer. - Security Considerations need to be added to discuss the lack of ICMP. DSCP code points are required to be controllable via SCTP down through DTLS. However this is not supported on all operating systems and it was discussed that it is needed to write text in the draft that further elaborates this point and the same regard the set of DF bit through DTLS. Gorry: Can we add specific text about what is required to implement the spec. I think it should describe what happens if the underlying network does not support DF, ICMP, setting DSCP values etc. Michael: Will add. Gorry: There has been some confusion about how to use multiple priority levels with SCTP and how this maps to Associations. Maybe we should add one sentences also around how the DSCP is used. Michael: Will add. The chairs asked whether the draft had been subject to any reviews from the Security Area. No reviews have been done yet. Eric Rescorla has agreed to do this. The chairs would like to see security review prior to close of WGLC. The next steps agreed upon were to update the draft, to issue new ID and then have a security review and WGLC. * Michael - SCTP PR Policies draft-ietf-tsvwg-sctp-prpolicies Presenter: Michael Tuexen. This draft is almost ready for WGLC. The size of the socket options was changed for counters. Authors need to add a socket option to control and monitor whether PR is enabled or not. This ID needs a new revision. When the next revision is there, the document will proceed to WGLC. Karen Nielsen offered to review during WGLC. Gorry: We need to also find additional reviewers, please volunteer: this is a very short ID. * Michael - SCTP head of line draft-ietf-tsvwg-sctp-ndata Presenter: Michael Tuexen. There have been no real changes since it became a WG document. The socket API portions need to be updated. The proposed scheduling modes need to be updated in accordance with rtcweb user needs. Cullen (as Rtcweb chair): I suspect that tsvwg knows more than rtcweb about what rtcweb needs in terms of scheduling modes at SCTP level. Cullen will provide text that may help tsvwg/authors of ndata evaluate which scheduling modes which are most relevant. Lars Eggert: The value and usability of multiple priorities decreases with the number of priorities (meaning that one should not have too many different priorities). Matthew Kaufman: There are two main rtcweb priority exists; high important and less important. Next step: further work and updates. About 5-6 people in the audience had read. Martin Stiermerling (AD): Please read and comment. Chairs: We need more people reading these SCTP drafts. Many drafts are not hard protocol drafts. 3.2) Individual Drafts * Cullen - rtcweb-qos (20) draft-dhesikan-tsvwg-rtcweb-qos Presenter: Cullen Jennings The purpose is to help webrtc browsers to know which DSCP code points to deploy given the requests of a webrtc application. The request from rtcweb application will be given in terms of traffic type & priority (very low, low, medium, high). Browsers shall consistently translate to a set of DSCP code points. The objective is to keep things simple and easy to use. The DART WG is set to produce an Informational RFC about when one can multiplex multiple flows with different DSCPs over the same 5-tuple. David Black will co-author the work. The work will be based on expertise from TSV and RAI. The DART WG will be in the RAI Area, but documents will be forwarded to tsvwg. Martin S (AD): Please participate in the work, and subscribe to the DART list to help get this right. David Black: Other things that that shall be done is to clearly define what the term "flow" means in this context. Proposed text is being generated this week. Math Matthis: I would rather encourage to use a different word than just "flow", webrtc-flow for example. Harald Alvestrand: Rtc-flow may not be the best word. Cullen Jennings: May use a different word. The term "flow" is overloaded. The terminology is to be aligned across the documents. Michael Tuexen: The JavaScript API can choose the priority on four levels. Data has different priority values set on a per data channel. Magnus Westerlund: Priority setting is going to be done on the level of a data channel. Problem is that when one gets down to SCTP one has only one DSCP code point per association. David Black: That is why we have the DART work to guide on how/when to map multiple different DSCPs to same 5-tuple flow. David Black: CS1 is supposed to receive a less then best effort service. While we have specs to say how CS1 should be handled, users using CS1 may get very nasty surprises. Priority inversion may occur when CS1 is not supported by the network or not implemented as less than best effort service. Mo Zanato: Priority inversion is one problem. General problem is that there is no direct mapping from DSCP to layer 2. The behavior is different depending on the link interface. Clarification need to be made in between link layer and layer 3 Ruediger Geib: What defines the CS1 treatment with less than best effort? James Polk: We have IETF RFCs that specify that CS1 is less than best effort DSCP. Ruediger Geib: Another issue is whether you expect network providers to provide all these different code points. The different code points may be set by the browser, but then they could be collapsed in the provider network. Justin Uberti: How does this stuff map down to 802.11? Pat Thaler: If you want better connection between DSCP and 802.11 priority levels then this is a topic that 802 has been thinking about starting work (in 802.11 community) and there is a proposal to start to deal with this for data center and to look into how DSCP should map to the 8 priorities. But what you want to do may depend on the bandwidth. On some link speeds you want audio and video to go on different priorities, this if there is little bandwidth in particular. On a 10G links you probably don't care so much. David Black: MPLS has at most 8 traffic classes. There is other stuff, e.g. ECN, competing for the 8 values, though, so one can't rely on having 8 traffic classes in general. Toerless Eckert: This is as good as we can get it. The DS mechanism is all that we have right now. Let's stick with this and move forward. David Black: Is it possible to get a warning into the specs that one may not count on CS1? I.e., that it can be an issue if one puts BE and CS1 into the same class. Pat Taylor: In 802.1Q, 0 is kind of normal priority and 1 is less than best effort. We don't specify how these are always used. Have only a recommended default. We don't assume that HW implements all 8 values. One may very well have that the HW collapses 8 into 3 or 4 L2 queues. Justin Uberti: Having many levels can be contra productive. If the granular levels are collapsed in the actual network, it would be better to have fewer levels that are actually supported. David Black: It is known that there is a major carrier which does not have ability to do less than best effort (CS1). Cullen/James Black: RTCweb must define what they mean with high, low etc. Then we need to find out if the translation table is right. Mo Zanato: Agree with Justin's concerns. We need to be careful about assuming application to understand this matrix. David Black: Applications are programmed according to these levels. We need to define/found out what are then the expectations. The translation table will be hidden in the browser. Chairs: This needs to be discussed further. Chairs: We intend to start a WG adoption call for this work. How many people had read the document? Approx 15 people had read the draft. Chairs: Who would support work on this topic here using this ID as a basis for this work? (Loud Hum for) Chairs: Who thinks either we should use another basis or that we are not ready to work on this? (No discernible hum) Chairs: This is considered clear consensus in the room. We will continue the adoption call on the list. End of 1st meeting 0900-1130 Friday Morning Session (2h30) WG Chairs present: Gorry Fairhurst James Polk David Black david.black@emc.com Note Taker: A Zimmerman, updated from audio archive. Chairs presentation. NOTE WELL 4) WG Drafts Agenda bashing, presentations were reordered vs. original agenda (reordered SCTP-PR vs GRE-in-UDP) * Joe - Recommendations for Transport Port Uses (5) draft-ietf-tsvwg-port-use 3 people had read draft; The Chairs are considering a WGLC to get community feedback. AD suggests to have reviews from APPs and SEC Area. Adrian Farell: This ID touches all people that use a port, pushing things out for early reviews, should go to all directorates to check if this draft got it right Gorry: We are keen to get wider feedback Martin Stiemerling (AD): It's ok to get this out and get feedback from all review directorates. The WGLC will start after this meeting. * Karen - SCTP Failover draft-ietf-tsvwg-sctp-failover An errata had been approved for RFC 4960. There were no questions about the content of the updated draft. Gorry: Do the current implementations reflect this draft. Karen We think so. Gorry: Is there experience of interoperability between implementations? Karen: Yes, between BSD and Ericson - including permanent failover. Michael Tuxen: The default default is "OFF". This is a sender-side mod only, we expect it to be interoperable. Karen: The work is chartered as EXP, based on CC changes proposed that would update RFC 4960, these are now not described within the current draft. Michael Tuxen: The ID now has nothing experimental described , thus this should be published as a PS. Gorry: Noted. I am interestred in feedback about this from the room - does anyone think that it may not be useful to publish this as a Proposed Standard. 5 people read recent draft. Fred, Michael will review this doc for WGLC. Gorry (as Chair): Will discuss the document intended status with the ADs. We then expect to make a WGLC on this document in the period after the IETF. Fred Baker and Michael Tuexen volunteered to review. * Randy and Michael - SCTP NAT Support draft-ietf-tsvwg-natsupp * Michael - NAT for SCTP 4raft-ietf-behave-sctpnat-09 - This was a Behave WG draft, please read. Karen: I have read both drafts. It is difficult to read one on its own. I question if these two drafts need to remain split, there will be rundant info, it would be cleaner to understand if both were merged into one. Lee Harvey : The two things related to each other. Do we need to keep life support for NAT, when will we stop doing NAT? Gorry: SCTP is being used, the WG needs to support this, and provide a way to move away from UDP encapsulation of SCTP to native SCTP. Michael: The NAT vendors invented something for UDP/TCP. at least some support SCTP - but not the correct way, SCTP support needs be specified to say how to do this as good as possible. Karen: It is relatively simple to do SCTP support in a NAT, The message should be to go deploy support NAT/SCTP, and clearly separate the simpler case for single-homed use - this separation should be clearer. Having two drafts makes it look complex Lee: multiple hosts behind a single NAT is more of an issue, more of a problem for enterprise grade NATs. Michael:The main difference for SCTP is if you are single-homed, a lot of stuff becomes simpler, but don't change port number. James Polk: The doc was split to divide the work between behave and tsvwg, Now the Behave WG is in this WG. author, we could merge the IDs. Michael: We started with one document. This would make life simpler, you can not understand one doc without the other, need a lot of cross references Gorry: I see two possibilities:: publish as a pair of consecutively numbered draft for consistency with other behave drafts, or make this separation in the doc and have one ID. Karen: I suggest we make one doc, with separation needed to tell NA(P)T implementors how to do single-homed, one for multi-homed section Magnus: The split came from different charters, long time ago. We can decide what is best. Gorry (Chair): The WG chairs will consider and propose to the ADs. * Lucy Yong - GRE in UDP draft-ietf-tsvwg-gre-in-udp-encap-01.txt Adoption call feedback had received two areas of feedback: Checksum usage for IPv6 and need to follow RFC 5405. Authors suggest network overlay is for a service-provider use, and the Guidelines may not be appropriate? David Black: The language in the second bullet worries me - There are design guidelines here that need to be followed, RFC 5405 on UDP is not a protocol spec., it's a design spec to help protocol designers specify the needed mechanisms. RFC 5405 is a set of BCP guidelines. Lars Eggert: Thanks for staying with us transport guys, thank. I agree with David, RFC 5405 is advice for people building protocols using UDP. You need to say how the mechanisms you need are implemented. It says what to put in new docs. There has been an analogous congestion control discussion for pseudowires. This is a general issue, not just this draft: It needs a general solution. Unfortunately, this will take time, we need to figure out which OAM mechanisms we need to be able to use MPLS over UDP, etc, and what to do this. The second bullet will take more time to work out. Some concrete examples would be good, with some explanation so that you can point to good text on why this is safe. David Black: If I pretend I'm a network operator, how do I know that congestion is sufficiently controlled by the network and this is not a problem? Lucy Yong: They do many things - performance monitoring tools and other measures. David Black: Please write about 3 paragraphs about that. Magnus Westerlund: How do you know how does a tunnel endpoint know this is safe? This is my concern. Lucy Yong: We need examples. Magnus Westerlund: The applicability statement requires a protocol mechanism, and we need to explain how this may work. Lars Eggert: Describe the characteristics, then giving examples where you can would be a good way; people who run networks can then figure out whether they run into these issues Gorry Fairhurst (individual): People use GRE in a lot of applications, in the middle of the network and to the edge of the networks to people's computers. We might find environments were different rules apply, . 2nd point: If you say you have to follow RFC 5405 you need some monitoring if you are following that guidelines. Lucy Yong: The prime motivation is for overlays. An applicability statement may be needed? Gorry Fairhurst (individual): I think we need to define the mechanisms for the general Internet case, if you can justify how to turn these off in your specific case. Lucy Yong: Both cases need to be noted. David black: GRE is used much more than what would be called overlays, I think this is needed for the Spec. Adrian Farell (RTG AD): As an AD I get the message from TSVWG. Adrian Farell: As a co-author, this ID does not say what it needs to say; I also think the MPLS in UDP draft needs to change - I know what needs to be said in that doc. It is helpful to categorise the type of networks, i.e., internet, cust/provider relationship, managed client/server relationship (some service providers are already shipping this), and the "flat" network. The different scenarios may need different warnings, advice, caveats. It is going to be a section, I see that text as moving this doc and the MPLS-in_UDP documents forward, but not the end. On a whole, net operators probably "get it," but they may not have noticed some of the issues that have bubbled up. This should primarily concern the TSV and OPS Areas. David Black: The RTG Area is also important - strong background in figuring out the difference between the different domains, and is a source of specific expertise to help with MPLS. Adrian Farrell: When we did pseudowires, we specified that congestion control may be needed, but there was some pushback - some people did not understand pseudowires then (but us pseudowire people probably did not understand congestion then) David Black: Categorising the different network scenarios is a good starting point. Spencer Dawkins (TSV AD): We can provide guidance, standards track, and explain what is not safe for Internet. We need to provide guidance on anything that may be deployed in the general Internet. I'm comfortable with where this is heading. Martin Stiemerling (TSV AD): Please check the notes when you are writing the new section. Yesterday in the TSVAREA meeting we discussed the topic of UDP tunnels. We will create a mailing list for discussing Foo-over-UDP. David Black: Intention is to use this list to discuss issues related to tuneling over UDP and the use of checksums with UDP in IPv6. This will allow an cross-area discussion, although the IETF work needs to be focused on TSVWG. Lucy Yong: The major concern about UDP checksum for IPv6. Gorry Fairhurst (individual): Using the full checksum is exactly useful for this, I like idea of saying this can be used in this protocol. Magnus Westerlund: What mechanism do you have to verify zero checksum is working? Lucy Yong: GRE also provides a checksum. Magnus Westerlund: No, that's not the requirement. You need a mechanism to know that zero checksum is being processed correctly by the network (end-to-end) and a mechanism to notify if this does not work. The ID needs to say how to do this. David Black: The need is to figure out how you know if packets go to the wrong place? operations monitor networks, tools need deploys to figure out what when something breaks Magnus Westerlund: You need to read the correct part of the applicability statement, and provide a mechanism. Lucy Yong: We may be able to require a v6 checksum, and use the flow label. Would that work? Gorry Fairhurst: An egress counter to see how good your thing is working. then you might know some of the answers to tell us the network was working or not forwarding, then you may know some of the answers to whether the network works. This would be the main thing you need to do the right transport thing and the statistics may be really useful to know that things are working at this level. Gorry Fairhurst (as TSVWG Chair): I'm not happy with the words "MUST be examined" - these words need to explain, and this needs changed. Lucy Yong: We will change it. David Black: When this stuff goes out, this will turn out in completely unexpected locations, same has happened with e.g. iscsi now used for all kind of cool stuff in virtualization. Will classification of networks by type, be useful here? Adrian Farrell: Classification is fundamental. the application advice may be different for some scenarios - I personally have no clue. Greg Shepherd: I don't disagree, i have a rough time imagining a use case where networks can survive with congestion. How would the protocols function in a heavy congested network? Bob Briscoe: there may be a misconception of congestion, i.e., congestion from an operations perspective renders a network utterly useless. whereas the transport perspective is that some level of congestion is normal and useful ... David black: This is about adapting methods to the network and you can not just rely on the apps to do the right thing, if they do not react then we would like the circuit breaker to get the network working. Greg Shepherd: If the app is doing the right thing, how do we know that circuit breaker wont create race conditions to terminate the flow? David Black: Th folks designing circuit breakers know about this, CBs need to react on timescales much larger than a CC method. Martin Stiemerling: We should work out what a circuit breaker is first. Shaun-Hung: I think it may be better to limit the scope of using GRE for this work, to areas where a CB is not needed. Gorry Fairhurst: This may be ok for "congestion control", it is not OK for a circuit breaker. I think there are scenarios where this may need to be used. The nightmare is that you may need this in the future in some cases - it may be good to have this mechanism available when we need it - and for cases other than this proposed scenario. Shaun-Hung: We can put warnings on the usage of the technology, if operators choose to not heed it, it is their choice Spencer Dawkins: Protocols may not end-up where expected. It is good to keep in mind. and obvious to me, the meaning of words to people is different for different people, discussion here is critical. The ADs don't "get paid" by "late surprises". As an example, the checksum need, is not only an integrity mechanism between you / me, but also check for why that packet ends-up at a specific place in the Internet. This is the best justification to discuss these issues on the mailing list. Adrian Farrell: This session had been valuable to me as author, some comments have indicated strongly, that people have different views where GRE/UDP might be used, listing these is helpful. Some of us come from a world where a circuit is something different that a pipe. Is it a pipe and a faucet? David Black: There is a s strong distinction between implementation and deployment/usage. In many cases there is strong implementation advice, and weaker requirement for turning it on (lots of security examples of this). Figure out what needs to be implemented just in case it's needed. Gorry (Chair): Let's take the discussion to the list - we will note the new list in TSVWG. 5) Individual Drafts 1 Bob - ECN Encapsulation (15) - There is a WG Call to adopt this ID, that end 4th March 2014. - Chairs need to send a note to IEEE if adoption proposed. Adoption call completed. David Black: INT area is interested in the wider topic of tunnels, and the ID on tunnels for INT area may proceed. Bob Briscoe: There could be one standards track doc update for all the tunnel docs. Gorry Fairhurst: ECN is not specified in the INT area, the ECN part of the work needs to be done in TSVWG. David Black: We have decided to keep these topics separate. Bob Briscoe: There may be a future need to write a document that updates sets of tunnel documents. Gorry Fairhurst: This is a separate document, at this time, lets just discuss this adoption call this time. Gorry Fairhurst: 19 people supported work on the list and/or at meetings. Does anyone have any concerns in this room? The document was approved as a TSVWG document Gorry Fairhurst: The Chairs will consult the ADs to determine the proposed status of this document. Spencer Dawkins: The IESG can change the status during ballot even; send it as BCP, easier to go down than up. Fred Baker: I am in favor, of adopting this and there at least 2 working examples DLC inFR, and IP-in-IP. This draft is consistent with my experience. Bob Briscoe: This is a mixture of spec and use. Gorry Fairhurst: We scope this as BCP - we will revisit the required status in WGLC. BCP requires more review. We need notify the liaisons that this work is progressing. Bob Briscoe: We can help prepare a draft liaison statement. Pat Thaler: IEEE will be meeting in 2 weeks. Gorry Fairhurst: Please review this draft and send comments to the list. * Ruediger - Diffserv Intercon draft-geib-tsvwg-diffserv-intercon-05.txt - WG Adoption call requested by author. This document is suggested as Informational to define a simple interconnection process for DS networks. James Polk (as individual): I am hearing that this may impact the number of classes availbale, does this proposal go all l the way to the enterprise? David Black: No - this is reading it wrong. This is an applicably statement, this is carrier with couple peers, diffserv slightly different. James (as individual): Does this propose 4 classes or 4 aggregates? Ruediger Geib: Four aggregates, the text is difficult on the definition of a class. David Black: This may turn out to be both class and aggregate at interconnection site. The draft should be written in terms of usage of PHBs and TCs. The carriers will be dealing with the traffic classes. James Polk (as individual): Are there 4 PHBs in terms of service classes. or DCSPs? There are 2 EF classes: voice and expedited; is that allowed because it deosnt seem to be, to be mentioned, set or aggregated. David: A choice has to be made, the draft will pick 4 PHBs (one will be an AF class which is actually a group of multiple associated PHBs), one EF treatment will be selected for this draft. This is draft does not apply to enterprise. There may be more than one PHB at the edge for EF. James Polk (as individual): This means you can aggregate multiple TCs to be used for a DSCP in the interconnect. David Black: This draft is not meant to change what happens in an Enterprise... Fred Baker: Actually it does, because the DSCP is IP, that goes e2e, and diffserv goes e2e. The statement on the slide is wrong - RFC 2474 forbids that sort of format-based aggregation of DSCPs - the DSCPs are a set of 64 numbers, with no aggregation structure specified. So, yes this approach does have an enterprise impact: If it maps a DSCP, this changes the enterprise view of what DSCPs are being used. The architecture was not designed to be used only within the originating enterprise. Gorry Fairhurst: focus if this doc is work for this WG, shall it be adopted Ruediger Geib: This case is quite common in crossing an Interconnection point - this is only about public traffic. This is what happens. The text is from Brian Carpenter. Fred: This is not what was intended by the original Diffserv architecture. Ruediger Geib: Penultimate hop popping in MPLS requires the DSCP to have meaning at the egress LSR. Gorry Fairhurst (Chair): We should focus here on whether this work is "doable" rather than working out the detail. We have seen the document a number of times, but I'd like to know as Chair if we can do this in the WG and get this correct for this application. James Polk (as individual): Fred's point is this is fundamentally a violation of RFC 2474, as there are 64 values that are being reduced to 4 or 8... this is the issue. Fred Baker: yeah, this is a piece of work that should be discussed here. Understand that this is fundamental change. I'm OK with that conversation happening. In the context of this being a fundamental change. Ruediger Geib: This is not the intent. James Polk (as individual): if you are talking about a L2 wrapper (MPLS) and taking a 6 bit field, and mapping it to a 3 bit field at layer 2, I might be in favor of it. If you you talking about a 6 bit field then this is something else. Which are you talking about: L2 (i.e. traffic classes) or L3 (DSCPs)? David Black (as individual): Regarding L2/L3 this was always intended as a L3 piece of work, this diffserv arch needs to be viewed in that respect. Diffserv explicitly stated, when admin domain changes, you can change all DSCPs. I see two enterprises, and a domain between. RFC 2474 and RFC 2475 allows this remarking. I do not see any change happening here. Fred Baker: The slides say there is an aggregation field, that is an architecture change. James Polk (as individual): : I'm sympathetic, looking for your stated goal; Problem with mapping 64 possibilities to 8/4 without the info to the endpoint to remark back to 64. (not with MPLS) you are mixing layers. Gorry (WG Chair): Who has read the draft? Gorry (WG Chair): How many people think that this work should be done here on this topic, not necessarily considering this draft. Against doing this type of work at this time? David Black (co-chair): I think it's not yet ready for adoption, we need another revision to clarify the scope and make it clear that this is not changing the diffserv architecture. Ruediger Geib: I'm bashed for rewriting draft both ways - remarking is allowed... Gorry Fairhurst: True. Fred Baker: I'm in favor of doing the work; concept of e2e service was the original idea, operators wanted to have override this in individual way. That mean we don't have e2e, we as a group have to get consensus what the right number is (4 or 5 classes that work in the core), we should have an e2e service class that allows us to have operation on the Internet. Gorry Fairhurst: We need to have one or two paragraphs (close to the abstract we already have) this must identify the intended scope and what will be changed. This will be the basis of the adoption call * Greg - Multicast UDP Guidelines draft-shepherd-multicast-udp-guidelines-01 - WG Adoption call requested by author. David Black (WG co-chair): Question to the AD: After the discussion in TSVAREA, is it better to have two guideline docs or one? Martin Stiemerling (AD): The intention was to have this separate, when we did not want to revise the original RFC (RFC 5405 on UDP unicast guidelines). Now an RFC 5405 update is clearly coming, so this could be done in one doc Lars Eggert: I agree, we could roll this multicast support into a -bis doc. That would be good. Gorry Fairhurst: I have multiple views: I think providing guidelines for multicast is good, on the other hand as a co-author, I have a list of 15 points where we have to revise basic guidelines. There are issues we didn't figure out, we need to reopen this draft. Greg Shepherd: Does this mean we re-open RFC 5405. Gorry Fairhurst: Yes, there are new things to do. Everything here seems to be good as a starting point for the multicast content. Greg Shepher: I'm fine with that. Toerless Eckert: Are there drafts waiting on this as a dependency? ( I don't know status). Just wording on the timeline. Multicast seems to be good along the way Lars Eggert: This blocking can be lifted by putting that section in those docs. Greg Shepherd: The multicast draft refers to RFC 5405 - it makes sense to do these two together. Lars Eggert: If this document doesn't say everything that needs, then maybe it needs to say more. Martin Stiemerling: The AMT doc can benefit from what is in here, but does not need to block waiting on this. Gorry Fairhurst (as individual): The UDP guidelines will be opened after this IETF, I expect comments on the WG list, and will ask for adoption on this list. * Tunnel Congestion Feedback draft-wei-tsvwg-tunnel-congestion-feedback David Black (as individual): I'm interested to see work in this space. Eric Nordmark: My understanding is, there would not be any data out of this for UDP traffic if it does not carry ECT. A: The tunnel calculates how much packet loss was seen. Gorry: This is different, because it uses ECN on the tunnel (even when traffic in the tunnel is not ECT) and the egress would drop or mark. therefore it is applicable to UDP traffic. Eric: Yes, this is an interesting problem to work upon. ???: It may be an IP application running, why do we in the middle need the ECN marks? David Black: If I understand this, it runs an ECN feedback loop over the outer tunnel header, tunnel looks like a link. when the details are worked out . I think is about the right place and structure. Dirk: I think this was intended to improve traffic management, not congestion control. do you have any analysis on interaction congestion control? A: This probably applies as a form of traffic management. Spencer Dawkins (individual): I think this is a mechanism that can be used by different people in different ways,detecting congestion (transport) figuring out what to turn off and where to (management) turn off. I'm wondering how many areas don't have an inter-area dependency? Bob Briscoe: As a response to Dirk, this is the same response as a proposal to apply conex in data centres, that uses ipfix; if you have conex packets, gives you that information from the source. This can be used instead of this, when you have conex. It is also beneficial to use ECN - since you can see the marks. A: We have comments so far: too much options in draft, we need to give requirements for operators to interoperate. Gorry Fairhurst: This is really interesting, refreshing appears to be doing congestion control, too much rather than too little. As such, chairs encourage discussion, interested in the use cases, clearly expressed, added to the requirements. If we can not do this properly, we don't have a protocol. Please revise the draft and discuss on the list. End of 2nd meeting