TSVWG IETF-78, Berlin, Germany WG Chairs: Gorry Fairhurst David Black James Polk Notetaker: Karen Nielsen, Richard Scheffenegger, Fawaz Saleem Bokhari. Session 1: MONDAY, July 29, 2013 Existing Liaison with ITU-T Study Group 12 Liaison on QoS Classes & markings https://datatracker.ietf.org/liaison/1241/ Document Status and Accomplishments No IDs in IESG, 1 ID past WGLC, 1 ID in WGLC, 3 IDs almost ready for WGLC. Remaining working group IDs: 4 IDs Charter & Milestones Review The hairs encourage the milestones to be revised and kept up to date. The meeting agenda was discussed. 2) Chairs - Drafts Under review for publication 2.1) Bob/Jukka - Byte and Packet Congestion Notification draft-ietf-tsvwg-byte-pkt-congest Status: Document has been through IESG review and came back with comments, in addition outstanding comments from WGLC are being processed. Changes were reviewed by Bob Briscoe including comments received from Dave Taht, Fred Baker, David Black. The document shall be revised to clearly decouple content from AQM BOF and work that has been done in TSVWG. This document shall make no reference to favour particular packets, e.g., small packets, and it shall be explained that the document applies to all (existing) AQM mechanisms. No forward reference to new generations of AQM or work anticipated from AQM working group shall be made. Martin AD: I think the presentation captured my understanding, and should not directly refer to the AQM BoF this week. Gorry: I agree. There is no intention to make this document obsolete in the work being discussed in the AQM BoF. Discussion and decisions: A document update is to come before end of this week. Under the new IESG process, this will pass through a short WGLC and resubmitted to the IESG. 2.2) Randy and Michael - SCTP SACK Immediately draft-ietf-tsvwg-sctp-sack-immediately Status: Some comments have been applied after WGLC. No question/comments. The document is ready for IESG review. 2.3) Note of work in Internet Area draft-bonica-6man-frag-deprecate. Heads up to highlight a proposal to the IETF 6man WG to deprecate fragmentation for IPv6. Gorry Fairhurst presented one summary slide on behalf of Joe Touch. There were note that if this work proceeded it would impact IETF transports used for tunnels, and prevent operation of PMTUD/PLPMTUD with SCTP, DCCP, etc. The draft also contains some TCP implications that should be verified. Dave Black (as individual): This will indeed impact tunnelling – more and more tunnels are being seen. PMTUD is supposed to work, but if it does not and if the stack cannot fragment the packet would blackhole. Michael Tuexen: This impacts SCTP setup messages, initial messages can be too large for PMTUD the PMTU. If fragmentation cannot be done, one would need to address this by updating the protocol spec and deployed stacks. Further SCTP today does fragmentation when it cannot change its mind (dynamic reductions of PMTUD and retransmissions of chunks). A consequence would be that SCTP would have to fragment data chunks to 1280 bytes. Roberto Peon: I think the intent is to mitigate complexity in the endpoints and transport layers do know how to perform recovery from lost packets. This could increase complexity at the endpoints. Reudiger Geib: A motivation is that operators are in favour of making things as simple as possible (removing fragmentation will simplify the network, less fragmentation is good). Gorry (as individual): This impacts other protocols that number segments, such as DCCP, and other UDP transports. Dave Black: Removing this could give a problem for IPv6 introduction, since it provides an incentive for transports to use IPv4. If enforced one will see IPv6 in IPv4 tunneling to allow for fragmentation (at IPv4 layer). Roberto Peon: This draft will encourage use of small packets for robustness - which is not a good idea. Bob Briscoe: Performance is all about getting started quickly - and this impacts this. If PMTUD needs to complete prior to start, this may block. Martin Striemerling: The AD’s and Chairs will speak and convey tsvwg concerns to 6man Chairs. Please follow this activity on the 6man mailing list. 3) Working Group Drafts 3.1) Joe Touch - Recommendations for Transport Port Uses draft-ietf-tsvwg-port-use Presented by Gorry Fairhurst on behalf of Joe Touch The purpose is to provide advice to protocol designers to avoid reinventing the wheel. Highlights: Protocol designers should not by default ask for a privileged port for new services, especially it should not be assumed that use of a privileged port provides any security. Security must be supported by specific security mechanisms. If no comments are received this document will be sent to WGLC. Discussion and decisions: Mike (various): Important to gather material on when you need a new port number or when you can reuse existing allocations. How can we free ports when we no longer use them ? Is it acceptable to use a port for a different purpose when it is no longer being used for the purpose for which it was originally requested. In reality it is hard to take back a port that has been allocated. Gorry: This is not about allocation/deallocation procedures, that is handled by an existing RFC. Mike (various): The slide mentions congestion control. RFC5405 is all right, but statements here (presented slides) are different in respect to considerations on the usage of UDP and congestion control given in RFC5405. Statements given on UDP usage should be in-line with RFC5405 (and should not be more restrictive). Conclusion (Chairs and AD): Comments are solicited on list. Other groups should be made aware and should be asked to comment. Good enough for the chairs to send a message to the different areas. Further feedback is expected. 3.2) Randy and Michael - SCTP NAT Support draft-ietf-tsvwg-natsupp Status: This document is thought ready for WGLC. Need people for reviewing. Discussion and decisions: Randy Stewart: There exists a document (draft-ietf-behave-sctpnat-08.txt) in behave wg that also describe NAT behaviours. Chairs: The document discusses in the same section both NATs and SCTP. Typically these are not implemented by the same people. For clarity the document needs to be revised so that changes to NATs and SCTP end-points are split into separate (sub)sections. Gorry: NAT traversal is really important. Should the document include requirement for all future SCTP implementations to support NAT traversal? Chairs: Above comments need to be addressed after which the document shall progress to WGLC. 4) Other Drafts 4.1) Ruediger - DiffServ interconnection classes draft-geib-tsvwg-diffserv-intercon-02.txt Chairs: The document uses unacceptable terminology, this needs to be fixed so that the diffserv meaning is clear. Ruediger Geib: There is a problem with terminology. Document follows current practises. Focus has been on solving the issues, terminology problems shall be solved. David: There are more problems than just terminology. It is imperative that it does not break routing. Susan Hares, David Black and Ruediger Geib will work to sort out the issues. Discussion and decisions: The draft will not progress until the terminology have been resolved. 4.2) Edward Crabbe - Generic UDP Encapsulation for IP Tunnelling draft-yong-tsvwg-gre-in-udp-encap Puneet Agarwal: This is backward compatible with existing equipment that use UDP ports for entropy, is that main argument? Anther alternative is to extend of GRE to provide entropy. That will not be backward compatible, but it does not add bytes. The extra bytes are significant for the processing in endpoints. Gorry F: There are statements that need to be fixed relating to the use of the IPv6 UDP checksum. The standards language needs to follow the published requirements. Answer: Will do. Bob Briscoe: It may be good to ensure extendibility of the header, and consider more than GRE? Edward Crabbe: This works with existing equipment. Does not preclude that GRE entropy field could come as another draft that can update GRE. Chairs: Need to address the RFC keywords and comments on the list. The work is of much interest. Expect a call for adoption before Vancouver meeting. 4.3) Greg Shepherd - Multicast UDP Usage Guidelines draft-shepherd-multicast-udp-guidelines Status: RFC5405 made a point of not describing multicast. This document picks up the missing pieces of based on solutions for congestion control for multicast. Please review. Discussion and decisions: AD (Martin Stiemerling): Now that it is clear that there are solutions it is good to have the draft written. This is an important missing piece that should be documented. Chairs: How many people have read this draft? (3) Chairs and AD: Work is firmly within charter. AD encourages more people to read it. The draft is being seriously considered for adaptation by tsvwg, but needs to have review. Greg will inform the Mboned WG and ask if people there can comment and contribute. 4.4) Sean Turner - Cryptographic Agility for the RSVP INTEGRITY Object draft-turner-rsvp-auth-update-00.txt Status (Sean Turner): Document as is should not be read. The existing Key Identifier fields can be used for the purpose, but clarification is needed. Once updated, comments are solicited. Chairs: Please read next version. Comments are solicited once document has been updated. 4.5) X Wei - Tunnel Congestion Feedback draft-wei-tsvwg-tunnel-congestion-feedback-00 Presenter: John Kaippallimalil (?) This proposes use of IPFIX to avoid needing to develop a new protocol. Hannes Tschofenig:: Why IPFIX? We have different protocols that could work. E.g., one could use diameter to pass the information around. Comments/others: Diameter is good for flow admission control, perhaps not for this. Bob Briscoe: Conex draft for datacentre, draft-briscoe-conex-data-centre-01, goes in the same direction and use IPFIX to do policing. Conex draft describe deployment scenario. Want to support this work for specification of solution. David Black/Hannes : Need to clarify the use cases for this. Mike: The use case is Mobile Backhaul. Jana Iyanger: Interacts fully with end-to-end congestion control Puneet Agarwel: Need to clearly define the time scaling of the feedback solution. David Black/Hannes Tschofenig/Others: Request for a write up of the problem statement in the draft. Need to nail down time scale issues, what will tunnel ingress use the information for, nail down the interaction with end-to-end CC, etc. John Kaippallimalil (?): 3GPP is doing work related to this, but this exact aspect is not within scope of 3GPP at present. Gorry Fairhurst: If the draft is adopted, the IETF 3GPP Liaison shall be used to make 3GPP aware of work. Chairs: Applicability to 3GPP need to clarified. Applicability to 3GPP and problem statement to be revised prior to liaison will be established with 3GPP. 4.6) Cheng-Jia Lai - Normalization Marker for AF PHB Group in DiffServ draft-lai-tsvwg-normalizer Cheng-Jia: Draft specifies functional requirements. Ask for others to implement the heuristics. Discussion and decisions: Chair: What would be standardized if the solution is not in the document? Cheng-Jia: Intended status is Informational. Bob Briscoe: It sounds like introducing a new algorithm rather than improving/correcting an existing one. Gorry Fairhurst: Solution is tested in lab (only). Interesting to know how it would behave in the general internet. Reudiger Geib: The work has merits, but I am not sure if this is related to transport. Hannes Tschofenig: This requires deep packet inspection. Not allowed in all countries. Chen-Jia: Open issue when there is encryption. Roberto Peon/Hannes Tschofenig/Jena Lyengar/others: A link to specific behaviour of codecs is problematic. David Black: This should interwork with end-point encoding. End-point encoding will assume that this is not done. Reudiger Geib: At entry point of the network charging can be based on DSCP codepoint. It would not work to change the DSCP codepoint to something else than what is charged for. Perhaps one could use congestion marking instead? Jana Iyengar: Experiments done are related to specific codec. Chair (Gorry): Should clarify if there are related drafts. There seems to be several drafts coming out that are working on video and interactions with AQM. Chairs and AD: Need to stay away from the individual codec. Need more discussion on the list. Please read draft and discuss on the list. Need to evaluate whether applicable for tsvwg. 6.1) Anurag Bhargava - RSVP support for PCN draft-ietf-tsvwg-rsvp-pcn Status: Comments received has been addressed. Chairs: This seems ready for WGLC. Does anyone have comments that should be considered before we move forward? Bob Briscoe: I gave a comment that RSVP aggregation is not needed at all thus questioning the relevance of the work. Is the comment taken ? (It is not). Is this document ready for publications? (hum for) (Mild hum against). The chairs intend to progress this document to WGLC. End of Session 1. Session 2 MONDAY, July 29, 2013. 5) Chairs - Work Group Overview The NOTE WELL was reviewed. 6) WG drafts 6.1) Randy and Michael - DTLS Encap of SCTP for RTCWEB draft-ietf-tsvwg-sctp-dtls-encaps PMTUD can be done at two layers (e.g. over DTLS). Do you have any platform-specifics that will require you to go some way? Cullen: I don't believe the PMTU is supported in DTLS Stuart Cheshire: If there is a problem with the API for Apple software, please log this. 7) Other Drafts 7.1) Cullen - DSCP and other packet markings for RTCWeb QoS draft-dhesikan-tsvwg-rtcweb-qos-00 Cullen reviewed why web apps need to set the DSCPs and needed advice. The proposed use of multiple DSCPs was discussed. Wes Eddy: Even without different types of media - video will use different markers for the same flow, and you will see remarking at network borders. Toerless: Mixing horizontal rows of codepoints was not in the spirit of the original use for AF41-AF42, and may not work. Application developers need to know what the experience will be to take advantage of the DSCP. Cullen: We discussed recommending specific codepoints in the webRTC work. Toerless: This may be very unpredictable when one network implements one PHB, and not another. It would be good to know real application experience. Cullen: The expectation is to guarantee nothing in the general Internet, it makes recommendations for what to set at the sender. Toerless: I think it may better not to use any markings, than to use a bunch of these mixed together. David: I suggest you do not mix audio and video on the same 5-tuple. Gorry, Toerless: I agree. Toerless: I think the differentiation implied is wrong. David: The use of AF4x is mainly to deal with drop precedence, this may be reasonable. EF is useful for audio, although mixing EF and AF4x on the same 5-tuple could loose audio/video differentiation. Toerless: Also note that some of the original diffserv work was never implemented. Predictible differentiation between AF4 / AF3 may in practice be very hard. Ruediger: I think this relates only to IP. Please do not mix random drop and other drop behaviours. You should not mix traffic across these flows because of admission control and queue drop behaviours. Ruediger: Is TSVWG chartered to change the QCI? Cullen: It isn't intended to change this. Ruediger: Can we add a normative reference to the QCI? Cullen: The draft will refer to 3GPP specs. Some vendors have implemented subsets of the multi-field specifier. ???: This has implications on terminal design and downlink/uplink, and experience in China Mobile indicates this expectation may not be realistic - it depends on what the core allows. Cullen: I think the intention was not to use multiple DCSPs (i.e. bundle) with 3G. Toerless: I think the key thing is the API. ???: You can not really bundle and also get the differentiation. If spec were updated, this may be possible in the future. Ruediger: Bleaching at edges of codepoints happens. You need to specify which architecture is being used: clients on a single network or clients across the globe. Cullen: Yes. We will revise the marking text. David: Don't mix the vertical traffic within the same 5-tuple. There are fine grain classifiers that only work on the bundle flow. Mirja: You may not know that setting the DSCP has any effect. Cullen: Setting DSCP codepoints is already done for audio and it helps. Gorry: Yes: Is this one code point per flow media-type? Cullen: Yes. It really does help in practice in some cases, with no negative effects, and sometimes positive effects. Gorry: Agree, if this is a DSCP for one media flow. Mirja (RMCAT Chair) I wish to note that DSCP work will not be done in RMCAT. Gorry: I agree, DSCP definitions belong in TSVWG. David: Do people have real information about performance of DSCPs through home gateways? Andrew: I sent comments to the list about using these specific codepoints with home Linux gateways. The broken piece of code has been the default for a long time - we may expect this old code to removed from Linux, but it does exist. Stuart Cheshire: If you implement this right (and also AQM and other things), it can work. However, if you use a 19$ gateway then it may have very different behaviour, and this may not be the thing that makes it work. Toerless: On congestion control, each flow should have their own congestion control domain - so that if one DSCP receives one treatment, we know the CC properties to use, and we may need to change mappings. Michael Welzl: I generally agree, but this statement might not be entirely correct. There can also be flows across a shared bottleneck, see work in RMCAT - different classes can share a bottleneck. David: You've received useful feedback, please also get appropriate references in there and make sure the QCI stuff is right. Chairs: Who has read the draft? (lots 10's of people) Chairs: Think it is important to do work in the IETF? (Many) Chairs: Think the IETF should not do work on this? (None) 7.2) James Polk - DSCP assignments for video draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt No presentation 7.3) Michael Tuexen - SCTP head of line draft-stewart-tsvwg-sctp-ndata Chairs: Who has read the draft? Chairs: Who think it is important to do work in the IETF? (Many) Chairs: Who think the IETF should not do work on this? (None) Chairs to ask the WG mailing list if they will adopt this as a work item. 7.4) Randall Stewart - Pluggable Stream Scheduling for SCTP draft-tuexen-tsvwg-sctp-scheduling-00 No decision was made, please continue this discussion on the list. End of Session 2.