TSVWG Meeting, IETF-78, Maastricht THURSDAY, July 29, 2010 Chair discussion: The chairs noted the "Note Well" The chairs noted the creation of the RSVP Directorate Discussion of draft status in the IESG and RFC-ed queue -: What is the status of the Router Alert draft? Francois: It is a WG document, there was no presentation this meeting, but the aim is to get reviews and then move to WGLC. Two IDs past WGLC: DTLS/SCTP and ECN Tunnel One ID currently in WGLC: RSVP Security group Keying Four IDs approaching WGLC: - SCTP Stream Reconfiguration - IANA procedures for ports and services - SCTP Sockets - SCTP Flag Chunks IANA Ports and Services Discussion, Joe Touch http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry", Michelle Cotton, Lars Eggert, Joseph Touch, Magnus Westerlund, Stuart Cheshire, 26-May-10, This looks at allocation procedures, unifies registries, and attempts to create common syntax, so that IANA registries are a lot more consistent, manageable, and so on. Pending changes: SRV service name is intended to be _service_transport_FQDN *only*, with exceptions only for legacy work. IANA will ask communities to update names. The aim is to go to WGLC in September, and this will be forwarded to multiple WGs. Gorry: Can I clarify whether the intention is to specify _TCP and _UDP as transports or as transport types? Joe: We plan to also enumerate _SCTP and _DCCP. Stuart Cheshire: This is still to be discussed. or example, there would be practicalities of getting people to delegate _DCCP and _SCTP. This is likely to be a hinderance to deployment. My preference would have been to have not enumerated transports, but we already have, and it is too late to change. Joe: Sometimes you want to know the protocol though? Stuart: No, clients know what protocols they use, in most cases applications do know which protocols they want to use. Joe: There are counter-examples, such as DNS. Stuart: We still need to discuss. Lars: As I recall last meeting, one suggestion was everything that is not _TCP is _UDP. We need a new draft to incorporate the various issues (including comments from IANA). Bob Briscoe http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest "Byte and Packet Congestion Notification", Bob Briscoe, Jukka Manner, 12-Jul-10, There is a new co-author for the new revision. Text has been reorganised, this responds to WG review. Working group comment - "it's becoming a little more readable, but could you please make it actually readable? Move things into appendices." Not ready for WGLC until more readable. Colin Perkins said he would send comments about the byte and packet congestion notification, and the ID still has a lot of history that can get in the way of reading the text. The RTP aspects of this is still on-going work. Jukka: The document holds a lot of good information, I moved a lot to the appendix to try to preserve the discussion. Gorry: The WG needs to review the document and check it agrees with the history, etc. I'll do this - other people also need to look at this. Michael Behringer http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-security-groupkeying "Applicability of Keying Methods for RSVP Security", Michael Behringer, Francois Le Faucheur, Brian Weis, 26-Jun-10, Discussion on applicability of keying methods (and group keying) to RSVP Security. There were numerous changes from -05 version. primarily addressing the SecDir review. There was an additional author (Brian Weis). Gorry: This is under its 2nd last call. So we need a few people on list to confirm they are OK (or not OK) with the delta over previous version. Michael: Bob Briscoe has already posted his comments. Michael Tuexen http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Kacheong Poon, Michael Tuexen, Vladislav Yasevich, Peter Lei, 12-Jul-10, Various updates to the SCTP API. The key thing is to now agree on a single generic method that is easy to use. Aim is to have this document by mid September. Gorry: The document has lots of implementor feedback from Linux, FreeBSD, and Solaris community. We need API reviewers, which are primarily external. Lars: I suggest we can ask the Apps Area to supply a review. Michael Tuexen http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-sack-immediately "SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 12-Jul-10, There were no comments. Michael Tuexen http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps "UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 11-Jul-10, There was a discussion on the best way to do UDP encapsulation of transports, but there was a sense that it should be per-protocol. Agreed to adopt as a working group document, to be confirmed on the list. Lars; The consensus was not clear, but the preference was for protocol-specific encapsulations. The AD decision was that we should not do more than one encapsulation for the same protocol. Stuart: I think we should see this through. This is the right way to do this and we should have done this from the start. WG Chair: Who has read this or a recent version? WG Chair: Wo would be willing to contribute: WG Chair: Who thinks this should be adopted as a WG item? Gorry: We will take this call for adoption to the list. Randy Stewart http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-nonce "ECN Nonces for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Neil Spring, 29-Jun-10, The document grew out of a request to add ECN to SCTP. It also talks about ECN-Nonce, which we may need to revise. The spec is implemented in BSD, possibly Solaris. Bob Briscoe: I definitely support ECN, the Nonce-bit cause me a problem. Gorry : I'd like to see ECN defined. Lars: ECN-Nonce is experimental, ECN is STD track. Gorry: We need to first take the decision about ECN. WG Chair: Who has read this or a previous version? WG Chair: Who thinks we should do work on adding ECN to SCTP? WG Chair: Who thinks we should not do work on adding ECN to SCTP? The authors will prepare a new document so we can ask if this can be adopted. The Chairs were fine for ECN-Nonce to appear in an appendix in the draft until the WG decides. We should anyway change the ID title to not include Nonce. Randy Stewart http://tools.ietf.org/html/draft-stewart-natsupp-tsvwg "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Randall Stewart, Michael Tuexen, Irene Ruengeler, 29-Jun-10, Discussion of trade-offs between this and RFC 5061, which most known Unix implementations support. Basically, NAT support is recommended. WG Chair: Who has read this draft? WG Chair: Who would support this as a WG item in TSVWG? WG Chair: Who thinks we should not do this or explore another way? Agreed to adopt as a working group document, to be confirmed on list. James Polk http://tools.ietf.org/html/draft-polk-tsvwg-intserv-multiple-tspec "Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1", James Polk, Subha Dhesikan, 12-Jul-10, Provides a way to apply multiple Tspecs to an RSVP session. There are 3 issues to be resolved, the authors did not have time to update the draft prior to the deadline. Dave McDysan: This is a good idea, but not trivial because TSpecs are multi-dimensional. This is in some ways similar to RSVP-TE, but there are some inconsistencies. Bob Briscoe: I have reviewed previous revs, but not this. There are probably inconsistencies - what is the ordering of the request? James: they should be in order of bandwidth, this hasn't been added to the Spec. -: There are issues with multi-range specifications and how you know how to compute the bound between two spaces. This is tricky. Toerless Eckert: This is useful. I would like to see the I-D include the ability to signal a range of "bandwidths" (currently list of bandwidths) for endpoint that have very granular encoding capabilities. -: I was not arguing that ranges would not be useful, just that it was not straightforward. Gorry: The draft has been talked about at previous meetings. Who has read the current version of the draft? Who has read a previous version? Francois Le Faucheur: The I-D still needs work, but is in good direction, so I would support it becoming WG document. Gorry: Who would contribute to the work, review versions, contribute text, etc? Gorry: This is an IntServ document and we would need a charter change approved to proceed. Can we adopt this? Lars: The WG is not yet chartered for this, but the charter could be updated. I see this particular draft has active support. I would like to see more discussion on the list from the group beyond the authors. The RSVP Directorate are intended to advise the Chairs on the issues and viability of adopting and progressing the work; and are expected to also participate in reviewing and commenting. Lars: I see more people today than I have seen previously? Lars : The push-back on RSVP came from the routing area, and were concerned that this had limited deployment in the general Internet. Fred Baker: That is not true. Lars: We still do not have much evidence that a Spec. is right and has been multiply implemented. Dave: I am pushing back on pockets of interest, we may also push-back on SCTP, to ensure this is reviewed. We have an RSVP directorate. Dave: We need to know we have real community reviewing and working on this. James: I do not think we will ever get that much agreement. James (as an author) repeated the discussion of whether RSVP should be in the IETF. The discussion largely repeated the IETF-77 discussion, and James said it appears to be required at IETF-79, IETF-80, and following. Lars: One way is to get people in TSVWG to work on and review the documents (and say they will do). There needs to be people doing this to ensure STD-track progression. Right now, it is hard for me to judge if an RSVP implementer can interoperate using this specification. If there were two independent implementations, this would clearly demonstrate the implementability of a Spec. Dave McDysan: I was volunteering to provide text for multiple scenarios. Francois: The last IETF considered a range of concerns. Gorry: The RSVP directorate has been contacted in the last few days and I am hoping they will soon get back to me. -: The old IETF ethos of "rough consensus and running code" requires two implementations. This seems a good idea. Gorry: I like that. Lars: I like it too. This seems to be one way to show that the specifications are readable and it can be implemented. Bob: The directorate has just started-up and they will be getting back on this. Gorry: We will work with the directorate and take advice. Dave: The ADs are discussing with Gorry about getting committed reviewers. I would like to see 5 good reviews sent to the list, and that would be a strong case to progress this. James: There may already be 5 people, we will work on them. Gorry: If you are a vendor wanting to implement or comment, or would like to be a reviewer send me your name after this meeting. Lars: I think it would be a good idea to say more about the rules to adopt new documents in TSVWG, indicating the need for another interested party to review, and we will say this in the Charter. Gorry: We will talk to ADs and RSVP directorate. http://tools.ietf.org/html/draft-polk-tsvwg-rsvp-app-id-vv-profiles "Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams", James Polk, Subha Dhesikan, 5-Jul-10, James says this seems straightforward. No comments on this draft. David McDysan: This seems like a good approach and seems a good thing to do. Francois Le Faucheur http://tools.ietf.org/html/draft-narayanan-tsvwg-rsvp-resource-sharing "RSVP Resource Sharing Remote Identification Association", Francois Le Faucheur, Ashok Narayanan, Subha Dhesikan, 8-Mar-10, This document is a small delta over the real resource sharing mechanism that has now been merged into draft-berger-ccamp-assoc-info (and that is progressed in CCAMP). So draft-narayanan could be either progressed in TSVWG (but would require reviewers to learn about draft-berger-ccamp-assoc-info) or in CCAMP (it would require a few cycles from CCAMP community). Lars: Why did the CCAMP WG not take the whole thing? Fancois: Lou wanted to keep the document base separate to the optional thing, which is not RSVP-TE, and so less relevant to them. Gorry: We will talk to the TSV ADs and Routing ADs about where it belongs. If needed, the RSVP directorate can be asked. If the WG has opinions please do send a note to the Chairs (and WG). Yoshifumi Nishida http://tools.ietf.org/html/draft-nishida-natarajan-sctp-failover "Quick Failover Algorithm in SCTP", Yoshifumi Nishida, Preethi Natarajan, 22-Feb-10, The problem is that during failover, RTO is doubling on each retransmission, and only retransmitted packets are getting through. Failover takes a long time, on the order of 60 seconds. The user is likely to have restarted application and started from scratch by that time. Suggestions: - carefully change RTO? - reduce path max number of retransmissions? - additional state in path management state machine Several possible ways forward, including doing nothing, changing default values, or adding the state to the state machine. Michael: I understand the need to optimise, SIGTRAN already does this. If you lower the threshold for an inactive state, and define the dormant state, we don't say what should happen. This could be a useful 1 or 2 sentence Errata. Jana: There is a timer reuse difference between inactive and heartbeats, I am not saying it is better or worse. Randall Stewart: I think we need something that says do not shut down, and do that minor update. -: All the implementations do this different ways. A short document may be really useful. Jana: A short paragraph would be good. Chair: This seems to be something of interest. The WG needs to figure out a way forward as an Errata, revised I-D or ancillary documentation. Lei Zhu SCTP compression requirements and profile Carsten Bormann: Should consider 2001 discussion of header compression in ROHC. The landscape has also changed. At the time we were short of people who understand this. There are probably now about 10 people who understand this, and we need to see if we can get enough people in the room to continue this work. Gorry: I think this WG is the correct place for this discussion. It would be interested to hear feedback on the list on the individual submission. Lars: We recently closed ROHC, and we did not see a lot of energy to complete the last few drafts in the WG. I would need to know that people were ready and able to work on this, for this to happen. Lei Zhu http://tools.ietf.org/html/draft-wei-tsvwg-nested-header-compression "Nested Compression in ROHC", Anni Wei, Lei Zhu, 21-Jun-10, Inge: Is there a work item in 3GPP on this? Lei: It does not seem an urgent task, we have some time to decide this. Janardhan Iyengar http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Martin Becke, Thomas Dreibholz, Janardhan Iyengar, Preethi Natarajan, Michael Tuexen, 1-Jul-10, There were two approaches, one large document or a few documents in a suite. The work could overlap other drafts that have been presented. How much interest is there for standardising at the IETF? -: If I remember, the same sequence number was used across flows. For short transactions, this may be an issue. You may need more than one level of sequence numbers. Jana: We are not proposing a mechanism. We do have ideas, but we would like to know if there is interest in doing this work at the IETF. -: I have seen enquires from people who want to use both paths of a multi-path SCTP connection. Jana: I am having conversations with Sebastian who is implementing mptcp, so there may be value in writing these down as SCTP. There are publicly available algorithms. -: We did turn this off by default in FreeBSD, because we did not have congestion control. We now plan to turn this on by default. This is expected to give much better performance. Lars: As far as the IETF is concerned, we do not plan to recommend widespread deployment of mptcp - this is being put forward as Experimental. This too may need to be Experimental. Lars: Are people interested in this, and also think it is useful? Gorry: Please do discuss this and see what way we should proceed. Gorry: Thanks for the meeting, and please do use the mailing list and comment on the drafts. This will greatly help the work to proceed promptly. Original notes: Fred Baker with updates from audio record.