Minutes TSVWG Session on Transport Protocols IETF-88, Vancouver, 1420-1550 TUESDAY, Nov 05, 2013 WG Chairs present: Gorry Fairhurst James Polk Note Taker: Karen Nielsen, Ericsson. 1) Introduction by Chairs: Milestones: Milestones that are in the past and which have not been reached would need to be updated. Authors of these drafts, please contact the chairs. Document Status and Accomplishments since IETF87: 0 new RFCs since last 2 (almost) in RFC queue (SCTP SACK immediately, Byte and TSVP PCN) 1 past WGLC (RSVP support for PCN) 0 in WGLC at start of meeting Only 4 remaining WG IDs. Consequently WG will be open for adoption calls for new IDs. To be started after this meeting. WG IDs for RSVP and a number of individual drafts in Flow Meta data are collected for discussion on Friday. In respect to slides shown by Chairs it is noted that SCTP scheduling, draft draft-tuexen-tsvwg-sctp-scheduling, is no longer relevant because the substance has been incorporated into SCTP ndata draft. 2) Chairs - Drafts Under review for publication 2.1) Bob/Jukka - Byte and Packet Congestion Notification, draft-ietf-tsvwg-byte-pkt-congest IESG feedback has been received. It will be approved for publication with comments and after update in accordance with comments received, go directly into the RFC queue. 2.2) Notices - Michael Welzl - Note of upcoming BoF proposal in TSV, draft-moncaster-tsvwg-transport-services. This is one topic that will be discussed as TSVAREA session. 3) Working Group Drafts 3.1) Joe Touch (proxy Gorry Fairhurst), Recommendations for Transport Port Uses, draft-ietf-tsvwg-port-use WG revision number 3. Some comments have been received. The purpose of the document is to provide a BCP for protocol designers. Changes since Berlin: Port definition is changed to accommodate for middle boxes. Step now is to have some reviewers and a WGLC. 5 people in the meeting have read the document. Comments: Alain Durand: Minor: A Stronger recommendation to economize on the number of ports should be given. There are disadvantages in applications that use many ports for NAPTs, this may further motivate port conservation. Major: The PCP RFC of the PCP WG defines has to negotiate ports to use. Behind a NAPT you need to negotiate the port you can use. This is an important consideration that may be added as an example to the section about being port agile in this manner. This document should be made known in PCP. Wolfgang Beck: We are already very good in conserving ports. Martin Shimmer (AD): This document is for people who have never been to the IETF but ask to use an IANA port. Conclusion: The chairs asked for people to review: Scot Bradner and Alain Durand volunteered. Before/during WGLC the document should be brought to APPS area for review. WG Chairs should send an email to APPS ADs asking for this early review. 3.2) SCTP Drafts 3.2.1) Michael Tuexen - DTLS Encap of SCTP for RTCWEB, draft-ietf-tsvwg-sctp-dtls-encaps This document is pretty stable (one statement added since last meeting: IP must be able to send packets larger then MTU). the spec had been implemented in Chrome and Firefox. No interoperability issues anticipated or seen. Comments are appreciated. The authors think this ready for WGLC. R Jessup: The current document reflects implementation in Firefox. Conclusion: WGLC is started today and will conclude in 4 weeks, please read and send comments to the list. 3.2.2) R Stewart and M Tuexen - SCTP NAT Support, draft-ietf-tsvwg-natsupp The document is stable. Comments were recently received, and the authors will need to address comments received. Conclusion: The authors will update the ID. The document relies on draft-ietf-behave-sctpnat-09.txt. The Chairs proposed that the WG should also adopt this supporting draft from the (closed) behave WG doc. Dan Wing volunteered as a document reviewer for this draft. Conclusion: Consistency of the two drafts to be checked and updates to be brought to the WG probably before the next meeting. Chairs would notify the WG of the intention to adopt this. A milestone would then be created in TSVWG. A related draft is also be proposed for adoption: draft-ietf-behave-requirements-update. The AD confirmed there were no issues are foreseen with adopting these former BEHAVE WG drafts in TSVWG. Conclusion: Chairs would notify the WG of the intention to adopt this. A milestone would then be created in TSVWG. 3.2.3) Yoshifumi Nishida - SCTP Failover, draft-ietf-tsvwg-sctp-failover Agreement has been reached on the previously open points in the draft. The result of recent discussions: Potential Failure (PF) function should be independent from CC. The authors suggested that text on cwnd adjustments on the PF paths will removed. Error counter handling will be independent from PF. Instead, an Errata will be filed for RFC4960. Thereby robustness towards the additional HB sent on paths in PF state will be provided by already defined mechanisms in RFC4960. Permanent Failover will be introduced as a viable switchback option. The socket API will be extended to give event state notification of PF state + control usage of switchback mechanism. The socket API of the draft will be the APIs supported by FreeBSD. After the authors have updated these issues, they think that this is ready for WGLC. There are no obvious experiments and the authors thus propose for PS. Karen: Ericsson SCTP SW supports the functions of the document, so does (or will) FreeBSD. Chairs: Since youÕre removing something that was in the WG draft, can you make sure you do not simply delete this, but leave a couple of sentences that explain that there is separate congestion control for each SCTP association, and that each therefore relies on RFC4960. Conclusion: The WG need to evaluate the new text and also evaluate the status of the document (PS or EXP). Please revise the draft. 4) Individual Drafts 4.1) Edward Crabbe - Generic UDP Encaps for IP Tunneling, draft-yong-tsvwg-gre-in-udp-encap The draft has been updated since the last meeting: Security issues noted with using a zero source port, this is now random. RFC 2119 keywords were introduced. The document is proposed for adoption by TSVWG. More comments are solicited. Two vendors are looking to implement. 10 people in the meeting have read the document. Comments: Agarwal Puneet: How does this compare to vxlan ? (not answered). Vxlan does roughly the same thing and is competing with this draft. Lucy Yong: There are at least 3 proposals out that do some form of encapsulation, should we standardize more than one ? At least two of the proposed solutions are widely deployed. Chairs: There is not likely going to be a single standard for all encapsulations. Agarwal Puneet: It is a good idea to ascertain the other proposals and how many one in IETF will like to support. Why not adopt vxlan as the proposed solution in TSVWG ? Pat Thaler: It is clear that there will be a couple of ones. It will be nice to limit the number. Chairs: WeÕd welcome discussion with the authors of other drafts. vxlan is a specific technology. GRE is an IETF protocol that is recommended for tunnels carrying various protocols, and that was the motivation for progressing this in this WG. Others using UDP should use the same style of approach. Conclusion: The WG started an adoption call on this proposal, to conclude in 4 weeks. The Chairs would like to hear of other variants. 4.2) Greg Shepherd (proxy Gorry Fairhurst) - Multicast UDP Guidelines, draft-shepherd-multicast-udp-guidelines Guidance on how to do PMTUD for multicast should be written. Chairs: The ID is within charter. Topic is appropriate, but we should now confirm this draft has the correct content and is the group ready to take it on. Are there important aspects missing? Are people willing to review? 3 people have read. This is too small a number to call for adoption. Comments: Scott Bradner: There is a SHOULD only for CC schemes. Security Section is empty (this draft is far from being ready to proceed). Conclusion: Chairs will request creating a milestone for this. Review is required of the current draft to determine the intended scope: Scott Bradner and Randy Stewart will review. Once scope is clear, the chairs then plan to start an adoption call against the new milestone. 4.3) Michael Tuexen, SCTP PR Policies, draft-tuexen-tsvwg-sctp-prpolicies-03 This defines two additional policies : one is used by RTCWEB and other used by IPFIX. The two are: Abandon after a number of retransmissions. Give priority to a message using which you can abandon existing lower priority messages in SND buffer. Socket API is included. This had been implemented in FreeBSD. Comments: Randell Jesup: This is needed in RTCWEB. There is running code in Mozilla Firefox. Anna Brunstršm, Karen Nielsen will review. Conclusion: Hums for and no hum against at meeting. Chairs started a WG adoption call, to conclude in 4 weeks. 4.4) Michael Tuexen, Randy Stewart, SCTP head of line, draft-stewart-tsvwg-sctp-ndata RTCWEB uses SCTP with arbitrary large messages, required for RTCWEB. The draft is not yet ready for WGLC, but adoption by TSVWG is requested. Next IETF the authors would have code and a doc for WGLC. RTCWEB is looking to rely on this draft rather than to rely on some other immediate. Randell Jusup: Right now there is a work around implemented in Firefox, we would like to see this draft for RTCWEB. 5-6 people in the meeting have read the document. Comments recently received that needs to be integrated. Conclusion: A hum showed support for WG adaptation: no people with reservations. The WG started an adoption call on this proposal, to conclude in 4 weeks. 4.5) Bob Briscoe - ECN Encaps Guidelines, draft-briscoe-tsvwg-ecn-encap-guidelines There is growing interest in ECN at L2. AQM and ECN were never intended only for IP. ECN has to be propagated up the layers. Document describes 3 different ways that ECN may be propagated upwards. The purpose is liaison with other standards bodies and other WGs on how to propagate ECN up from the lower layers. Intended status is BCP, thus providing Guidelines for writing specification on how to propagate ECN up from L2 protocol (e.g., IEE.802, TRILL WG) and tunneling protocols (e.g., GRE, L2TP) for authors who are not ECN experts. Authors think that a PS will be needed to update ip-in-ip tunneling protocol (INT area or TSV for INT) but it is too early to call. Chairs: We will consult ADs about the draft and how to to work with other SDO bodies. Fred Baker: Should this be BCP or INFO ? Operators prefer BCP to be really current practices and until this is the case, it should be INFO. Pat Thaler: Content is about how to make things better in the future. Chairs: An INFO RFC may also use RFC 2119 keywords. 3 people indicated that they had read. Not enough for adaptation call. Chairs: We will try to sort the position with the aim to proceed for WG adoption, but the chairs need to discuss procedure before adoption. ** FRIDAY: TSVWG Session on DS/RSVP 0900-1100 Friday, Nov 08, 2013 WG Chairs present: Gorry Fairhurst James Polk David Black Note Takers: Richard Scheffenegger, Michael Ramalho Gorry presented updates to TSVWG milestones. 6. Working Group Drafts 6.1) Georgios Karagiannis - RSVP for PCN draft-ietf-tsvwg-rsvp-pcn, Revised draft after WGLC Substantive technical changes made after WGLC, another revision is needed to better align PCN usage of RSVP with location of RSVP decision point. No one objected to the general theory of operation, but the text needs more review. Georgios agreed to another draft update and then TSVWG plans to hold a second WGLC. No other issues from the floor. 6.2) James Polk - RSVP Application-ID Profiles draft-ietf-tsvwg-rsvp-app-id-vv-profiles This is related to a draft in the mmusic WG, and the WGLC is being delayed to align with activity in mmusic. No discussion from the floor. Thought ready for WGLC. 7. Individual Drafts not related to Flow Meta Data 7.1) David Black for Ruediger Geib - diffserv-intercon draft-geib-tsvwg-diffserv-intercon Two primary topics: 1: Dealing with IP precedence. New taxonomony ?DSCP Aggregation Prefix? to describe the behavior of legacy network nodes that apply QoS based solely on the former IP Precedence field, ignoring the 3 least significant bits of the DSCP. 2: Treatment of Network Control traffic. Approach on the slide was worked out with IDR WG people, including one of the chairs, but the specific text needs some more editing, and the IDR WG should take a look. The plan is to revise the draft, then issue a call for WG adoption. Also, a liaison statement has been received from ITU-T SG 12 Liaison ITU-SG12 regarding mapping between GSM Association IR.34 and Diffserv - the mapping work going on in GSMA may or may not be consistent with IETF DiffServ specifications. In addition, use of IR.34 may be isolated to GSMnetworks. The liaison statement does not require a response, so the IETF liaison manager for ITU-T SG12 (Al Morton) will convey tsvwg's appreciation for the information to the SG12 rapporteur. 8. Individual Drafts related to Flow Meta Data 8.1) Amine Choukir - Flow Metadata Signaling with RSVP draft-zamfir-tsvwg-flow-metadata-rsvp This draft proposes to extend RSVP to convey flow-related metadata based on the framework. A discussion around privacy concerns started with this draft, but concluded during the next one. Gorry: Is the new type intended to replace the legacy value? Toerless: No, both would be supported. Basic answer is yes, although Toerless mentioned other ways to extend new functionalities in RSVP. Martin Stieerling: Asked if there are any security considerations? Amine: Not at the moment, more discussion needed. David: Be careful of who is supplying the metadata: The user and app developer are not the same person. The app can not be trusted to get users privacy right. 8.2 Charles Eckel - Framework for Signaling Flow Characteristics draft-eckert-intarea-flow-metadata-framework Discussion focused on the rationale behind the draft. The goal is for a mechanism for applications to let operators to add value by improving the QoE of the service being used. Made the case for flow metadata. The WG discussed shortcomings of existing mechanisms such as ACLs (labor intensive), DPI (impossible with encrypted signaling), and other Application Layer Gateway (ALG) shortcomings. Discussed some use cases of metadata illustrating roles of producer and consumer of metadata. Discussed incremental value of metadata. Discussed a mobile network use case for OTT. Discussed some issues in the Security Considerations of the draft ? two basic areas: encoding and candidate protocols to use (PCP, RSVP, STUN, and more). Discussion of this draft centered on the privacy and related security aspects. Two classes of flow metadata and related uses were pointed out (the framework and its anticipated uses cover both): - Metadata that describes the traffic (e.g., in order to apply QoS) - Metadata that names the application generating the traffice (e.g., for monitoring and troubleshooting). The latter raises significant privacy concerns - the Area Director (Martin Stiemerling) indicate that a BOF would be required on that class of metadata, this would also have to ensure sufficient IETF community awareness of and attention to these privacy concerns. Alex Mayrhofer: In light of discussion on privacy this week, asked Charles what are the concerns. Do we need a privacy considerations section? Al Morton: Why not just let the application signal only the flow needs? David Black: security may need to be different for the two classes of information identified in the use cases Francois: Discussed a topic in another WG meeting that metadata could be a mechanism to disseminate information to lower layers that need it (to provide the best low latency performance). Martin Stiemerling: Discussed potential for metadata to lie about what it needs (e.g., you might still need DPI). DPI will still be used to verify if what the apps tells is valid. Wolfgang Beck: If you don't have an incentive to use low priority flows, high priority flows will be used. This needs some authentication. Brian Travel: Trust-but-verify is hard to do in a DPI world with everything is encrypted. Andrew McGregor: Trust-but-verify issues is verification by statistics. Martin Stiemerling: Need consensus on security/privacy issues on the naming of the flow (e.g., I am application X and I am user Y) and how to describe the flow characteristics. Spenser Dawkins: Update on history where parts of an attribute that are encrypted, but some components were in the clear. This was proposed by an IETF AD and he could not get consensus. Martin: RSVP runs end to end along the path, with STUN you are sending off-path which exposes the information. David Black: Need to separate out the naming/privacy-revealing components of this draft and structure a BOF to come to consensus on this issue and to take this issue out of this draft. Further discussion lead to the proposal of holding a BOF on the entire framework as opposed to splitting these types of metadata in advance. A hum was taken - there was strong interest in holding such a BOF and very little opposition. The draft authors will follow-up on this and a related mailing list (used for discussion and organization before the BOF) with the ADs. 8.3) Toerless Eckert - Priority dropping to improve real-time draft-lai-tsvwg-normalizer This presentation was for the working group's information only. Important points from discussion: Colin Perkins: I strongly disagree that an RTP header extension is the place to put the QoS markings of the type Toerless is speaking about. The RTP header is also encrypted in most use cases. I suggest looking at RTP shim, but draft for that is still work in progress for avtcore. David Black: Is the remarker codec aware? [no] recommended way for a codec, remarker only for cheater, which send high fraction of high priority video frames - result in lower user experience Colin Parkins: Even after such remarking, some important packets (e.g., Video I-frames) still have higher priority than other competing traffic, so this is a net win by comparison to no marking. This is better than down-marking all the packets. Zaheduzzaman Sarker: Asked a similar question about packet dropping without knowing the relative importance of a packet/frame and what to do when you have to drop. Gorry: What do you need TSVWG to do to take this work forward? Toerless: I do not know. David: OK. This is an informational presentation. No work is currently requested of this group. 9. Late Breaking Talk deferred from TSVAREA meeting Bob Briscoe - Immediate ECN This presentation was added to the agenda because there was not time in the TSVAREA meeting. Early results for having predictably low queuing delay of DCTCP. Tests the waters on a redefinition of ECN, and discusses coexistence of traffic w/redefined ECN and traditional traffic (only reacts to drops) in the same queue. The actual end-host will smooth its own output knowing its own RTT. A box attempting to know if the end host is behaving correctly would actually have to calculate the RTT of that flow to verify that this flow is behaving as it should (and that may not scale). **