TSVWG, IETF-86, Orlando WG Chairs: Gorry Fairhurst James Polk David Black Note-Takers: Enrico Marocco - Monday John Leslie - Additional notetaker, Monday. Scott Brim - Thursday TSVWG Monday 12 March 2013 -------------------------- * Chairs The NOTE WELL was presented The chairs summarised document status and accomplishments. Gorry: Any agenda questions? (silence) * Charter & Milestones Review, Chairs Gorry: Milestones, blue imminent, green future Drafts Under review for publication: draft-ietf-tsvwg-sctp-udp-encaps (IESG issues to be resolved) draft-ietf-tsvwg-byte-pkt-congest (AD feedback available) draft-ietf-6man-udpzero (publication requested) draft-ietf-6man-udpchecksums (publication requested) No questions nor comments from the room. * Recommendations for Transport Port, Uses Joe Touch (presentation proxy by Gorry Fairhurst) draft-ietf-tsvwg-port-use Joe says the document is almost complete. Chairs: Please review and comment to the list - people could read an individual sections and provide feedback! No questions nor comments from the room. * SCTP endpoint encapsulation using UDP, Michael Tuexon draft-ietf-tsvwg-sctp-udp-encaps * UDP Encapsulation of SCTP Packets draft-ietf-tsvwg-sctp-udp-encaps Michael presented SCTP UDP encaps. No questions nor comments from the room. Chairs: There will most likely be a short WGLC. * SCTP NAT Support, Randy and Michael draft-ietf-tsvwg-natsupp Michael presented SCTP NAT support. The authors believe the document is ready for WGLC. Chairs: Who had read -04 or -05? - 3 people had read this. Dan Wing: It would be useful to provide guidance on when it is desirable to use UDP encapsulation versus NAT. Michael: It would be good to have text describing why you want to use and the limitations. Dan Wing: Do we need a happy eyeballs-like technique for a host to decide when we use UDP encaps or native SCTP? Michael: This is out of scope in UDP documents. Michael: In the UDP document we say the limitations, this does not provide guidance. Dan: What is the motivation for people to use native SCTP? Michael: The UDP stuff is transitional. Dan: We should work on "how to end the transition". Dan: There are multiple ways hosts need to figure out which to do, should we take this task on? Michael: I would like people to prefer SCTP native. Dan: How do we start to get to this stage? Toerless: Is the SCTP/UDP intended to be Standards Track? Gorry: Yes. Toerless: One way to indicate preference for native could be to make SCTP/UDP experimental. Jana: Is the port number configurable? Michael: yes. Jana: I think we should define a transport selection mechanism that covers multiple transports. Carsten Borman: We should have ways for the applications to control. Dan: The NAT draft is little confused about how a host figures out a NAT is on path, looks like that will work (NAT-awareness stuff). Chairs: We need more feedback from the list. * DTLS Encap of SCTP for RTCWEB, Michael Tuexon. No questions nor comments from the room. Please read and comment on the list * SACK immediately, Michael Tuexon. The authors indicated this was nearly ready for WGLC. Chairs: What about security? Michael: We will say something lightweight. Chairs: We plan a WGLC on the next version, who can review this draft? Jana: I will review the draft. Martin (as AD): SCTP and the reason why there is so much about SCTP will be explained in the TSV-Area tutorial this week. * SCTP multipath failover, Yoshifumi. Jana: This is valuable. Chairs: Do you offer to review the next version? Jana: Yes. Michael: This is good. -: This is valuable work. Jacob: Has bfd been proposed as a possible way to detect a path failing. Lars: This is not between routers, bfd does not apply. Salvatore: I support this and I will review. Toerless: What is the policy for fall-back to the first path? Randall: This is the way SCTP is designed, it will go back to the path on the next heartbeat. The application decides how to do this. This should not change this. Chairs: Please continue to work on this draft. * Liaison with ITU-T Study Group 12 on QoS Classes & markings, David Black David presented the response to the liaison from ITU-T SG12. No questions nor comments from the room. * DiffServ interconnection classes, Ruediger presented by David Black. draft-geib-tsvwg-diffserv-intercon-02.txt This is not WG draft, we need to figure out what to do about this. Usually in diffserv we leave it to the operators to determine DSCPs, at Interconnection points this becomes complex to map between carriers. Shitanshu: When there is a mapping between two carriers, is there some sort of signalling? David: Kind of yes. Black: Currently there are four proposed classes. Use default PHB for these four, top two must be admission-controlled, third is congestion-controlled (three PHBs), how to mark, fourth is default. Sue Hares: Are you assuming this conditioning is working between the networks? If so, how can you guarantee that? David: I think you're expected to condition twice Sue: So you are conditioning on both ingress and egress? David: Yes. There are three domains here (sending, interconnect, receiving), there may be ways to optimise. Sue: Are we assuming point-to-point connections? David: I've always assumed point-to-point, but that is actually a good question. Black: Diffserv is fully specified by 64-entry table; in practice two constraints: need backward-compatible (three zero bits), still some gear out there, e.g. MPLS, drops three bits, we need to write careful text around this. Somehow we have to compress 12 classes into four, will go to 14-to-four. David: Maybe we should also consider the Scavenger class. James: I agree with this. Matt: There is importance in protecting BGP. David: Please take that to the list, and see what needs to be done for BGP. Al Morton: There are 4 classes plus 4 additional classes. Maybe the solution is six classes? Black: We need to find the right people to talk about it, eight is all there is. Chairs: We should confirm these points on the list. * SSLA Exchange, Shitanshu. draft-ietf-idr-sla-exchange-00.txt This draft is from the IDR WG, about out-of-band SLA exchange. This topic may pertain to TSV. Chairs: The work is probably complementary to the other work on QoS/DS, but the present draft does not say much about QoS classes/models. Shitanshu: This propsal tries to highlight the parameters associated, and how to exchange those parameters. Torless: What is also important is to specify how much resources you are allocating to the 4 classes. Sue: There are mechanisms and an information model, the mechanisms belong in the IDR WG. We are working on a generic information model. Chairs: The TSV chairs and IDR chairs will talk. Brief presentations of new drafts will be included at the end of Thursday's meeting. TSVWG Thursday 14 March 2013 ---------------------------- * The NOTE WELL was presented again. * RSVP for PCN, Anurag Bhargava draft-ietf-tsvwg-rsvp-pcn David Black: Bob's primary concern is to note that the PCN integration decision does not have to be made at the ingress node, it could be made anywhere. Please check the draft for implications that the decision has to be made in a specific place. Just be clear in use of the word "decision", the PDP can be anywhere. Bob: I agree. Anurag: I thought it was clear that the PDP was at the ingress David: In the general case, the PDP could be elsewhere. Anurag: Sure, can do. Bob: For the application to PCN, the PCN WG's scope was to have the PDP only at the ingress, but a draft from TSVWG should state all the options. Anurag: I will edit and come back. David: Describe e2e piggybacking versus separate aggregate reservations. Anug: The authors prefer separate aggregate reservations as that approach is closer to RFC 4860. David: Work this out on the list. Gorry: Are there more reviewers? Francois: I have already commented on the list. Chairs: Please continue to work on this draft. * Adobe RTMFP (for Info), Michael Thornburgh draft-thornburgh-adobe-rtmfp Martin Stiemerling: This is intended to be AD-shepherded as an Informational RFC. Michael Tuexen: Do you specify the congestion control you are using in detail? Michael: There is text in the draft to specify you must use congestion control and give limits, but we do not specify exactly what they use in Flash. They want to leave it open ended so people can experiment. People should be able to use TFRC for example. (In their implementation they use TCP-like now, but half as aggressive.) Michael: I would like information on what is in current flash. Michael: Yes, we will provide that. -: What does this describe? Michael: This describes the base transport protocol, not everything you need to interwork with Flash, e.g. it does not specify the cryptography protocol. Gorry: Please read the draft, and send comments or questions to the mailing list or author. * vvprofiles, James Polk draft-ietf-tsvwg-rsvp-app-id-vv-profiles-00 - James Polk James : There are no known open issues, all issues in two recent reviews have been addressed. I am now looking for a concurrent last call with MMUSIC draft, possibly in May. Chairs: Who has read this or a recent version of the draft? - Only 1 person read it; no comments at the mic. Chairs: In that case, we will need offers of people to read and comment on this. James: I will find some. * Diffserv update, James Polk draft-polk-tsvwg-rfc4594-update-03.txt draft-polk-tsvwg-new-dscp-assignments-02.txt - James Polk and David Black Meeting discussion was solely on the rfc4594-update draft. James: This splits interactive video into two classes. David: Why is the Hi-Res class needed? James: It implies a different quality of "video". David: Why? James: Customers want telepresence and certain types of video treated differently from other types. In an uncongested situation the two classes are treated the same. When congested, people want Hi Res to be "uninterrupted". -: Is this "hi-res primarily interactive"? There are two classes already, do we need a third class? Lars Eggert: More broadly than this, you will always find an argument someone needs another diffserv class, but at some point we will run out. I see the use case, but you can prioritize traffic by other ways, e.g. match on the 5-tuple. Francois LeFaucheur: In general I am sympathetic with prioritization, but I think "hi-res" is not a good name, the difference is it's prioritized. Gorry: I think we should in general conserve codepoints, if you the planned usage is not a clear case. David: Please hum if you support this use-case, if you think it is not a good case, or you are unsure. - The hum for yes was faint. No was about 2x faint. Not sure was a little under Yes. David: That was not sufficient to be able to see consensus, we will take the decision on the list. David skipped questions 2 and 3 about repurposing of CS4 and resulting repurposing of CS5. David: For the case of "audio", should we generalise this as a replacement name for "telephony"? David: Please hum if you support this use-case, if you think it is not a good case, or you are unsure. - There was hum for, no objections in room. David: This seems to have support, we'll confirm this on the list. David: Should a voice-admit PHB be added as a class in addition to the current EF PHB? - There was hum for, no objections in room. David: This seems to have support, we'll confirm this on the list. Martin Stiemerling: People on list are invited to join this discussion. * Guidelines for Multicast use of UDP, Presented by Gorry draft-shepherd-multicast-udp-guidelines-00 This is a new draft, to describe transport advice for multicast. Chairs:Please read the draft, and comment on the list. * UDP Tuneling, Lucy Yong draft-yong-tsvwg-udp-4-ip-tunneling-01 UDP encaps for IP tunneling to specify UDP encaps for use where ECMP and LAG. It uses entropy (UDP source port) for ECMP to ensure related flows go over same path. Tunnel type would be in UDP destination port. UDP is not used for demuxing or identifying an upper layer service similar to VXLAN. Magnus Westerlund: This draft requests use of the UDP checksum, will it conform to the Guidelines for usage of UDP zero checksum? Lucy: Yes, this is cited in the draft. Magnus: You can not just refer to the reference, you must satisfy requirements for using a zero checksum and demonstrate you need this. Lucy: OK. Bob Briscoe: There are tricks you can use to add general extensibility to tunnels. For example, extension headers behind the UDP headers. Lucy: OK, send more information. Martin Stiemerling: Why is a different port number used for each tunnelled protocol? Lucy: We want to be able to interpret the payload. Martin: This could be dynamic. Lucy We will address. Lars Eggert: Why is there no version field, e.g. in a shim header? Lucy: We wanted to be lightweight, this is the first draft. Lars Eggert: How does this relate to NVO3? There are too many narrowly-scoped tunnelling schemes being proposed. Lucy: This is not another tunnelling protocol. It is just encapsulation. Gorry: Is between routers and middleboxes or between endpoints? Lucy: The former. Gorry: In TSVWG this is regarded as a tunnel. Chairs: I have seen lots of comments on the list and some more at the mic. Please revise the draft, there is lots of expertise to help you. SCTP individual submission drafts. * SCTP PR Policies, Randy Stewart draft-tuexen-tsvwg-sctp-prpolicies. This is sender-side only, the draft is planned to be used by RTCWEB and by IPFIX. Chairs: Since there are no comments at the mic, please continue to develop the draft. * SCTP Ndata, Randy Stewart draC-stewart-tsvwg-sctp-ndata - This deals with sender-side head of blocking. SCTP needs this to support sending gigabyte messages. Richard: Could a receiver-side also define a queuing policy? Randy: This is sender side scheduling, there are some perils in receiver side. Michael Tuexen: Receiver side is hard to do. Chairs: Please continue discussion on the list. * ECN Tunnel Guidelines, Bob Briscoe draft-briscoe-tsvwg-ecn-encap-guidelines-02 Revised draft had input from other SDOs. Chairs: This needs people to read and comment. * RSVP Multi-instance object, James Polk draft-polk-rsvp-multi-instance-object-01 Gorry: How many people had read this or a recent version of the draft? - 5 people have read it. Chairs: Please discuss this on the list.