Thursday, November 8th, 2012 TSVWG meeting 1: Differentiated Services Note Taker: Ken Carlberg 1) Agenda The meeting started with bashing the agenda. The chairs decided to go through several presentations by James Polk on the topic of differentiated service in terms of background, context, followed by a general discussion and a liaison with the ITU-T. - David Black suggests grouping presentations 2, 3, 4, 7, into the initial discussion. Then, presentations 5 and 8. - Matt Mathis suggests we should have a roadmap for diffserv. 2) James - DiffServ Standards Problem Statement 3) James - Update to RFC 4594 4) James - Assigning Additional Realtime DSCPs There was general consensus that the previous work in differentiated services concerning multimedia conferencing was incomplete and that more "granular" work needs to be conducted. 5) Shitanshu - Diffserv for LLN traffic The draft-svshah-lln-diffserv-recommendations was presented to the group. It was agreed that more reviewers were needed, with comments, before it the group can consider adopting this draft as a working group document. 7) ITU-T Study Group 12 Liaison on QoS Classes & markings It was also agreed to consider the "interconnect of core providers" liaison with the ITU-T discussing code point mappings. Further discussions would be taken to the list. 8) James - RSVP MULTI_INSTANCE Object Finally, there were no objections in changing the multi-tspec draft with the multi-instance draft (draft-polk-rsvp-multi-instance-object) since the new draft incorporates a design proposed by Lou Berger. However, The authors need to decide which "RSVP multi_x" option is to be used. 6) David Black - Chair lead discussion on way forward with DiffServ The following minutes represent a more detailed exchange by participants during the first day of the TSVWG meeting Topic: differentiated services - background and context - James Polk) talks about important differentiated services, and the audience feels there are more (David Black agrees) - (Joel Halpern): likes the liaison from ITU-T and states we don't want to ignore it and that Eliot Lear has volunteered to put an outline of a response. Joel wants to make sure we explain "this is what we are doing" - (James Polk) states that the concern from ITU-T is that there is a a "scaling" concern -- e.g., 10's or more sending domains - (David Black) his understanding is that most of the proposed ITU-T work is "informative" in terms of mappings. - (Matt Mathis) thinks there is missing an IETF document (i.e., a more informative document is needed) in the existing series of differentiated services RFC series. - (David Black) notes that the ITU-T work does not reach out to the end systems Topic: Differentiated Services standards problem statement - Note: this involves updating diff-serv service guidelines (rfc-4594-update-01, new-dscp-assignments) - (Lars Eggert) makes the point that the network can only chose one characteristic (low delay, high throughput), and so the ingress router only marks the packet with one of those characteristics - (Matt Mathis) The hard part for application writer is knowing what the network supports in terms of code points - agreement from James Polk that code points should not be hard coded/wired to applications - (Matt Mathis) Question - does James Polk make a distinction from realtime and streaming video? James says yes, but Matt says that the vast amount of video in Internet is streaming. James makes the point that one carrier has "telepresence" rooms, and wants to work differently between that and lower bandwidth video - (Matt Mathis) advocates a hard constant for delay sensitive apps versus relative importance. So in a sense, you don't want to exceed ranges of jitter. - (Bob Briscoe): says that differentiated services for providers has more to do with which services/apps are more important to them - (Jabber room) the problem is the application or network edge is causing problems - (James Polk) tries to make the point of dividing one service class into two (asking for more granularity) - (David Black) states that "we" didn't make a distinction between one way and bi-directional/interactive when first defining service classes. He makes the point that the concern is the human complexity with what we currently have. - (Michael Ormalo?: cisco) asks if the traffic class label is good for us to discuss in this working group? Polk responds, "yes" - (David Black) rfc-4594 update: what is broken, how badly is it broken, and should we add service classes? - (Paul tomes?) doesn't think its "broken", but feels we should take a look at it - (David Black) there is a suggestion that multi-media conferencing was not done properly when first defined. So, what does the room think about this? Audience "hum" thinks James Polk is correct and that a new more granular class is needed. Particularly, RFCs 4554 and 5527 needs some work. Black states that we need to put this on the list and discuss how many more things we need to fix. - (Pat Thaler?) observes that 802.1 is making a more granular distinction between voice and video Topic: interconnect liaison with ITU-T - (James Polk) describing set of code points (?) for the interconnection of core providers. - (Gorry Fairhurst) asks if we should make a new set of recommendations for a particular interface. - (David Black) thinks we should. As Chair, he asks the room if we should work on this? The room (by show of hands) indicates yes. So we'll put this on the list (Joel Halpern) thinks we don't need to do anymore at this meeting. We should state "this is an interesting problem, and we should do something about this" Topic: Differentiated Services recommendations for LLN class (machine to machine, sensor networks) - (audience): ask the speaker to define "converged network". He feels that one needs to take into consideration of IP and proprietary networks - (audience) should bring up queuing proposals in draft - (Gorry Fairhurst) asked if any recommendations require changes to existing RFCs? Response from speaker is that they want to produce a guideline. The speaker is then strongly urged to use an existing code point(s) because its much harder to get a new one(s). - (David Black) asks what is the proposed work in relation to rfc-4594? Does the speaker plan to deploy/support 4594 within the network? response was inconclusive. - Note: only roughly 4 have read the draft and the authors are encouraged to have others read it and comment on it (David Black) asks the presenter, what do you want of us? how do you want us to publish it? The response is that he wants this working group to adopt this document. Gorry responds by stating that the WG can't discuss adoption at this time because we need more reading and public discussion Topic: rsvp multi_instance - (Ken Carlberg) Question: does this add priority policy element. The response is yes, the pre-emption policy element - Note: no one read this draft, which is a replacement of another working group draft. Gorry notes that the WG replacement of the draft may be fine, but a decision is needed first as to which option within the draft is to be chosen before the working group can advance this draft. ----- Friday, November 9th, 2012 TSVWG meeting 2: Transport Protocols Note taker: Mirja Kuehwind 9) Chairs - Work Group Overview - Rolf Winter was thanked for serving as a tsvwg co-chair - David Black was welcomed as a new co-chair The operation of RSVP-DIR is being updated. To try and get more efficient progress of RSVP-related drafts we will review directorate membership and then assigns future reviews to people based on need and specialism. Directorate members who feel unable to do reviews would be replaced to keep the process running smoothly. 10) Georgios Karagiannis - RSVP support for PCN The authors had received reviews via the RSVP directorate and some input from Francois during meeting. Bob: I have also done a review now and will post this to the list. Gorry: Is the review about RSVP or PCN? Bob: Both. I agree with the terminology, and the main point that it aggregates and de-aggregates in one hop. My comments also look at the location of the PDP - at least to point where this is discussed. Gorry (WG Chair): Everyone please check that this clearly addresses the requirements by PCN? PCN people please look at this. 11) Randy Stewart and Michael Tuexon - SCTP NAT Support The authors suggest proceeding to a WGLC, if we do not need to fully specify multi-homing behind a NAT. Gorry (as Chair): We need to know if the WG wants to fully specify the multi-homing behind a NAT. If we proceed with just a spec for the none multi-homing case. Is there anyone in the WG who is not happy with this? (None). Martin: The ADs would be okay to go with single home case first. There are dependencies with rtcweb. Randy: It is not that hard to add this text, but it will take time... Michael: We can try for orlando. And if it does work, we may request to submit this. Martin: That's fine for me. Michael: I think rtcweb does not need this use-case. Gorry (as Chair): OK, revise for the next meeting, if there is not time to supply the missing parts we will then prepare for a WGLC and include this as a specific question. At 9:40 the meeting was transported to a new room. 12) Yoshifumi Nishida - SCTP Failover draft-ietf-tsvwg-SCTP-failover - This is a new working group draft, please read this version and comment on the list. 13) Joe Touch (presented by Gorry Fairhurst) - Recommendations for Transport Port Uses The presentation describes several issues that need WG inputs, these were reviewed in turn. 1) System v. User ports -. Lars: I like this. -: I liked this concept that there was an underlying authority. Maybe it can be done differently but we should decide if we want to give up this concept? Lars: Trusted operating systems do have some port model. Carsten: There are systems where it does make a difference. 2) Port discovery is a big issue - we ned to define ways to do this. mDNS is one. Carsten: COAP has this issue with DTLS, where they would like to see several codepoints made available to identify non-DTLS usage (but no agreement yet). Michael: Are you trying to send encrypted and unencrypted over same port? Why not start unencrypted? Carsten: There is no start, these are single datagrams. The first byte identifies protocol. Lars: That may be your specific problem? 3) Copies of services Toerless: This would need to be higher layer multiplexing then and have dependency if protocol supports that. Lars: Joe is aware of this: many people are unclear of using header bits for multiplexing instead of using different ports. 4) Local services Gorry: People develop apps that are thought local/private networks, and then become Internet - It can be hard to change later David: This is not simple. There is also the potential for local use to conflict with Internet use, avoiding clashes, and simplest could be to allocate for the more general case. I'm happy to help Joe. 5) Joe Touch (presented by Gorry Fairhurst) UDP Services - Comments on proposal Toerless: I do not agree with the list of "should" on this slide. Lars: This should point to RFC 5405. Are there additional needs? Gorry: I agree, if you build "bulk" apps then it is important that you do these understanding the transport requirements. Bob: I do not think we should defining how high speed apps should work in this draft. 6) Discovery Toerless: This is an important topic. This is not an easy place to make recommendations. Toerless: We should also mention guidance on IP multicast address requests as well as port requests. Gorry: I agree there is a need to point to this. Lars: I just saw a use-case like this, requested because firewall holes can not be opened for a dynamic port. Lars: There is other work on this in the IETF on this topic (e.g. mDNS-ext). James (as Chair): If you came to the Mic or have thoughts, then I encourage everyone to send comments (especially small text) to the list to help address these issues. Gorry (as Chair): We will need to make sure other IETF areas see this - it may not easy to solve, we as a community have to work this out! 14) Randy Stewart and Michael Tuexon - SCTP drafts draft-stewart-tsvwg-SCTPecn ECN for SCTP SCTP-ECN There were no comments in meeting on this draft. Gorry (as Chair): We have already determined this falls within the Charter. Are there any comments on suitability for adoption? (None). Gorry (as Chair): This was previously discussed, so the Chairs will call on the list for adoption. Reviewers are needed draft-tuexen-tsvwg-SCTP-dtls-encaps DTLS Encap of SCTP for RTCWEB The authors report this has been implemented in Firefox. James: Did the rtcweb wg make a decision to use this? Magnus: SCTP/DTLS is useful for webrtc, and on their roadmap. Martin (as AD): The total number of reviews for SCTP review has been low, people should read this please. Gorry (as WG Chair): Who has read this version? (2 people h) Gorry (as WG Chair): We will call for adoption on the list. This call will be copied to rtcweb. Would people review or contribute? draft-tuexen-tsvwg-SCTP-sack-immediately STCP SACK Immediately This was discussed previously, and had 2 or 3 protocol reviews sent via the list. The issues had been corrected in the new revision. Gorry: Does the introduction now show clear use-cases (raised in previous reviews)? Michael: This is addressed. It avoids delays e.g. in set-up of a communication but depends on the application scenario. Michael: This could be informational or standards track, which? Gorry (as WG Chair): The status can be decided by this working group. Who has read this or a previous version? (5) Gorry (as WG Chair): We will start a call for adoption on list. draft-tuexen-tsvwg-SCTP-multipath Load Sharing for SCTP There is interest reported by the authors. There is no conflict with other SCTP draft, this draft has a different author list. Jabber: It seems SCTP is mostly used in a data center and there is no use for multipath as there on gigabit links. Michael: In this case, load sharing might help in getting a faster failover.Gorry (as WG Chair): I would like to judge if there is interest in this WG adopting.How many people read the draft? (few) Gorry (as WG Chair): We will ask the list to find reviewers. Proposed future Work on SCTP The authors said they were planning two future SCTP API drafts. Gorry (as WG Chair): This work seems that it may fall within the charter of tsvwg. Please prepare a draft and the WG will review if this is something they think needs to be done. The authors suggested future work to support SCTP transfer of large objects. Lars: Why do they need to send large (interleaved) objects? - Why not a shim layer above SCTP? Randy: It would be easier for the app to have one interface, rather than requiring something extra to prevent head of line blocking. This requires an additional sequence number. Wes: This keeps the architecture simple, but complicates SCTP. Gorry (as WG Chair): Supporting large object transfers implies a change (large or small) update to the protocol spec, and also (possibly a minor change to the SCTP applicability. - these require discussion by the WG to explain why this is needed. 16) Magnus Westerlund - Applicability Statement for the use of IPv6 UDP - The document changed from informational background to an applicability statement for using UDP, and will be submitted to a new WGLC. Gorry (as WG Chair): The new PS status does update middlebox treatments, and the way apps use UDP, we will repeat the 6man WGLC in TSVWG. 17) James Polk - RSVP Application ID Profiles RSVP-VV-Profiles Gorry: The mmusic chairs have confirmed that there is a need and we can do this in this WG. Toerless: This looks good to me. Will the string change as soon as this has an rfc number? James: Yes. Georgios: have reviewed and provided comment and I'm satisfied. its useful and should be adopted Gorry (as WG Chair): Who has read this document? (4). Gorry (as WG Chair): Are there any notes of support or reason why we can not adopt this document? Gorry (as WG Chair): Are there any notes objections or think this is not a good idea? (None) It was decided the WG would immediately start a call for adoption for this document as a work item. 17) Ken Carlberg - Reactions to Signaling from ECN Support for RTP/RTCP - The document was designed to be informational. Feedback on the mailing list had been commenting on this draft, and there were lots of questions. Mirja - There are a wide range of methods.Is this intended to be CC as well? Ken - It was intended to focus on ECN as a follow-up to the work on RTP with ECN. Mirja - Why is the titled restricted to only ECN? it could be also loss? Gorry: This seems like a matter to decide later. Mirja (as RMCAT Chair): If this goes ahead please post WG calls and ask for reviews in the RMCAT WG. ?: should we specify what is done or should we leave this to the applications developers? Ken: We would like to make recommendation about reactions to congestion Ken: We do not want to make specific recommendations at the moment, but could point to RMCAT. Michael: Is it a survey or a recommendation? Gorry: I am not sure we really know if this is documenting or advising - let's start from the view of presenting things that are known. Gorry (as WG Chair): Please revise the document and continue to develop this on the list - it looks like we need to look at this again. 18) Bob Briscoe - Guidelines for Adding Congestion Notification Authors plan to liaise with others who are engaged with lower layer standards and how these are used. Jabber: Is this work within the charter? Gorry: Good question to ask. David: This is clearly in scope, in the same way as RFC 6040. I'd be happy to volunteer help on data centre experience. Gorry: This appears to offer advice and document best practice, but not specify other protocols? Bob: Yes. Gorry: I think this topic is in scope for TSVWG. 19) Randy - Quick Start Plus (draft not presented, no remaining time). End.