TSVWG Meeting at IETF 94, Yokohama, JP WG Chairs: Gorry Fairhurst and David Black Note Taker 1: Pasi Sarolahti ---- Session 1 (110 min scheduled out of 120 min total) 1. Agenda 2. Status/updates (WG Chairs) (15 minutes) Recommendations for Transport Port Number Uses (RFC 7605) draft-ietf-tsvwg-port-use DTLS Encapsulation of SCTP Packets (RFC-Ed) draft-ietf-tsvwg-sctp-dtls-encaps Quick Failover Algorithm in SCTP (in AD review) draft-ietf-tsvwg-sctp-failover NAT Behavioral Requirements Updates draft-ietf-tsvwg-behave-requirements-update (WGLC requested) [The chairs need to identify reviewers who will look at this during WGLC] * David looking for reviewers -- no one in the room volunteered RSVP Multiple Traffic and Flow Specifications draft-ietf-tsvwg-intserv-multiple-tspec [This work is likely to be cancelled, unless new interest is shown in this draft soon.] RSVP Application-ID Profiles for Voice and Video Streams draft-ietf-tsvwg-rsvp-app-id-vv-profiles [This work has been cancelled due to lack of energy at this time, the WG milestone was removed.] Charter & Milestones * Agenda bashing: Karen's SCTP tail-loss presentation has been moved to Thursday, because she is waiting some more results for the presentation, UDP magic numbers moved to Monday to compensate. * Ari Keranen (as ICE WG co-chair): Announcement: ICE has a session on Thursday morning, with transport related implications to be discussed, hopefully many transport people will be able to make it. 3. WG Coordination (Activities related to TSV in other areas) (5 minutes) Chairs - Encapsulation Considerations draft-ietf-rtgwg-dt-encap [On-going in routing area (also work in Int Area on tunnels).] Chairs - The Benefits to Applications of using ECN (at IESG) draft-ietf-aqm-ecn-benefits [Follow-up after IESG.] ---------------------------------------- 4. WG Drafts (WG Last Call completed) 4.1 David Black for Gorry Fairhurst - Network Transport Circuit Breakers (15 minutes) draft-ietf-tsvwg-circuit-breaker On "Is RTP-CB still to be included?": * Bob Briscoe: A network cricuit breaker is a third party, but the RTP-CB is not, that's a fundamental difference. This needs to make very clear how it differs. * Colin Perkins: I disagree with Bob's characterization of the RTP circuit breaker about being only a network circuit breaker, that is just one use case. * Bob: Just because they have same name, doesn't mean that one is an example of another. I think this draft must define much more clearly what the scope is. The draft is unclearly written, the concept of a flow is not clearly defined. * David's conclusion: The RTP-CB stays in, but clarifying text is needed - see latest version. On "What protection is needed for control communication?": * Colin: The RTP-CB requires protection of the control information (there is text about an authentication mechanism), I agree with review comment. * Bob: I sent mail to the list this morning about the definition of a flow, and about covering tunneled congestion feedback, but this is in conflict with the other ECN tunneling draft. I think we should split the tunneling part as a seperate work and make it more consistent with the other work. ------------------------------------------- 4.2 G Fairhurst / L Eggert - UDP Usage Guidelines (15 minutes) draft-ietf-tsvwg-rfc5405bis * David suggesting dropping clarifying pointers to specific sections/documents that are expected to be relevant for particular use cases (e.g., in routing) * Lars was concerned about adding new stuff or restructuring. He just wants to get this particular revision done to update the current position. * Erik Nordmark: There are other encapsulation drafts that are in the same space. We should synchronize between documents, and make sure these cite this. * David: Can you do a quick cross-check to point out the issues? (Erik agreed) * Lars: I propose we get the commenting done soon, at least before the winter break. ---------------------------------------- 5. SCTP Drafts 5.1 David Black for Michael Tuexen - Stream Schedulers and User Message Interleaving for SCTP (idata) (5 minutes) draft-ietf-tsvwg-sctp-ndata [no comments, progress expected before next IETF] 5.2 David Black for Michael Tuexen - SCTP Network Address Translation Support (5 minutes) draft-ietf-tsvwg-natsupp * Karen Nielsen has some editorial comments, but thinks the solution is ok. 5.3 Maksim Proshin - RFC 4960 Errata and Issues (10 minutes) draft-tuexen-tsvwg-rfc4960-errata This is currently an errata tracking draft. WG adoption likely to be requested sometime in 2016. * Mirja Kuehlewind: Why does this list erratas in a seprate document, why not have real .bis document? * Maksim: We plan to do that as a separate next step. * Karen: Such a document is helpful clarification, to motivate certain changes. * David: Would it be possible to treat this draft amd 4960bis as a pair of drafts to be published? This one explains why, other one specifies the protocol. * Karen: We could use this draft as an informative reference. Agree that approach, working these in parallel. The given list (Improvements slide) also proposes changes to the protocol, we should take in only very important and safe changes to update the standard. Some of the listed items might be rejected. We want to have discussion about them. * Lars: This could become an Informational appendix, instead of separate draft. * Karen: An appendix is more limited in space. Need to spend time polishing the information * David: Feeling of the room seems to be to go with two separate drafts [This is consistent with the procedure discussed at previous TSVWG meetings and seems to have worked well for SCTP in the past.] 5.4 Karen Nielsen - SCTP Tail Loss Recovery (15 minutes) draft-nielsen-tsvwg-sctp-tlr (presentation moved to Thursday) ------------------------------ 6. UDP Drafts 8.2 Tom Herbert - UDP Magic Numbers draft-herbert-udp-magic-numbers (10 minutes) * Martin Stiemerling (for Cameron Byrne from Jabber): It is very strange to me to do this for a middlebox. Is anyone fron a middlebox is saying they want this form of number? * Gorry Fairhurst (from Jabber): When is this more visible than the DST port? (e.g. what happens inside a tunnel?) * Ans: RTP payload - Web RTC example results multiple layers of encapsulation within UDP. * Colin: Similar, but different magic numbers were chosen in STUN/ICE, conceptually this is very similar. These numbers were carefully chosen. we should look at RFC5764. * Brian Trammell: Why is the magic value chosen like it is? How does it work with currently deployed application protocols? In a similar case (SPUD) we looked at protocol specifications to see if anything matches the chosen number. We should choose the number carefully based on available information. * Colin: RFC 5764 specifies guidelines on picking these numbers. [Aside from David: Well, actually see draft-ietf-avtcore-rfc5764-mux-fixes for how this really works, as RFC 5764 has turned out to be incomplete in this area.] * Joe Hildebrand: You need to do something that is doable on the fast path (I am just trying to answer why middlebox would care). * Mirja: We also need a magic number in SPUD because we needed to talk to middleboxes. I'm not supporting to reveal the application name information to middleboxes. A middlebox needs to know what kind of traffic, it does not need to know what the application is. * Joe: +1 to Mirja: In SPUD we are trying to hide as much as we can, we only expose what the network needs to see. There is a middleground we can try to approach. * Lars: Why is something in the UDP payload something that we need to standardize? Applications (new protocols) can, and do, what they wish with the payload. * Ans: Middleboxes need to support this, a uniform way is helpful. * Bob Briscoe: I don't agree with Lars. Middleboxes can check the application payload even without a magic number. Middleboxes still need to work with traffic that does not co-operate with them. Take a look at GUT we did with Jukka Manner, it also has a magic number. * Colin: In practice this is using it as a multiplexing shim layer. We are defining a new protocol that runs on top of UDP. If we accept this, we accept this as an architectural design approach. If you do this right, it can be used by new protocols. * Joe: The goal of this is to get on the fast path of middleboxes, many applications would not necessarily use this. It would be interesting to have a standard way of generating a good magic number. * Tom: I don't see this as a tool for multiplexing, I want this to be simple. -------------------------- 6.1 Chairs - Transport Options for UDP (5 minutes) draft-touch-tsvwg-udp-options * Gorry (from Jabber): IIRC, UDP-Lite started its life the same way (specified using the same IP protocol number as UDP). * Joe Hildebrand: (notes missed the first part of the comment). There is Cisco IPR on this approach. * Tom: There may be problems with offloading, etc. [See slides, this is being explored.] * John ??: (missed comment) * Bob: There might be a case that firewalls check whether the length fields are consistent. * Mirja: I like this idea, very curious to see. Makes easier to implement something on top of UDP? * Joe: This opens door to including metadata with UDP ------------------------------ 6.2 Mirja Kuehlewind/Brian Trammell - Requirements for the design of a Substrate Protocol for User Datagrams (SPUD) (20 minutes) draft-trammell-spud-req * Lars: Please keep those two things separate (SPUD and stackevo). Don't merge the two together. * Tom Herbert: Should we use something else than UDP as a protocol number? * Joe Hildebrand: If you want to ensure that doesn't get deployed, feel free to pick another number. * ??: When SCTP was developed, one idea was to use it over UDP. It picked a different protocol [and checksum], all sorts of problems appeared with middleboxes. We need a way to identify protocols on top of UDP. * James ??: Was 6lowpan header compression considered? You could potentially compress more. * Brian: We haven't thought about it, nobody brought it up. Please come talk to us on the SPUD list. * Mirja: We haven't seen any blocking or differential treatment in our measurements. * Brian: The SPUD office hours on Wed morning --------------------------------- ---- Session 2 (120 min scheduled out of 120 min total) --------------------------------- Note Taker 2: AARON FALK (aaron.falk@gmail.com) 6. UDP Drafts (continued) 6.3 Lucy Yong - Generic UDP Encapsulation for IP Tunneling (20 minutes) draft-ietf-tsvwg-gre-in-udp-encap Lars will send a pointer to the randomization RFC for TCP to list (RFC 6056). AD: For a well-managed IPv4 network MAY set UDP checksum to zero, it doesn't say why. I think this is wrong to base this on current implementation issues, and instead the document really ought to say "MAY" and then say for example to address current implementation performance. Need to confirm draft text is consistent with tunnels drafts. --------------------------------- 7.1 Bob Briscoe - Guidelines for adding Congestion Notification to Protocols that Encapsulate IP (10 minutes) draft-ietf-tsvwg-ecn-encap-guidelines Brian: Unity Media (German ISP) had a behaviour that set CE. This information did not originate with Apple, it was available via open sources. Ken: The rationale for recating to ECN marks may be different - some 3gpp specs recommend codec swapping in respond to CE. Joach Meyer: from Huawei & 3gpp router vendor, not an expert on ECN. Bob's report is being read by the 3GPP groups and we should expect a reply by Dec 2015. This presentation goes further. Will you bring this to 3GPP as a company contribution? John (co-author): We will discuss offline on how to best take it to 3GPP Dave: We probably won't last call this draft before 2016; thanks to 3GPP for the level of interest they are taking in this matter. --------------------------------- 7.2 David Black (on behalf of authors) - DSCP and other packet markings for RTCWeb QoS (5 minutes, no slides) draft-ietf-tsvwg-rtcweb-qos There are 3 drafts addressing this issue and they are not yet completely aligned. The team will align the drafts. This draft will ask for WGKC once that is done. Cullen: No disagreements were identified, the work is to figure out where text should go. --------------------------------- 7.3 David Black - Diffserv interconnection classes and practice (10 minutes) draft-ietf-tsvwg-diffserv-intercon Pat Thaler, Broadcom: I am not comfortable with the lack of room to support something like DETNET (deterministic networking), although DETNET initially would only be on a single administrative network. David: That's a different usecase. This is about standard interconnect, we need something to allow more cosnistent deployment now. Also, I plan to push back hard on feature creep given the limited number of codepoints available for Diffserv in MPLS - which this draft intentionally maps to. --------------------------------- 7.4 Xinpeng Wei - draft-ietf-tsvwg-tunnel-congestion-feedback (10 min) Tunnel Congestion Feedback David: This proposed new IPFIX methods to be specified in another group - is that group OK with this? Brian: I have no problems with the IPFIX aspects. The work is continuing --------------------------------- 7.5[new] Chairs - Relationship of Circuit Breakers to Tunnel Congestion Feedback (10 min) draft-ietf-tsvwg-circuit-breaker draft-ietf-tsvwg-tunnel-congestion-feedback No disagreements with chairs' proposal. Gorry (as editor): I don't quite agree on the detail ... I think the measurements that you would need for tunnel congestion control can be something more than for a CB, but I agree these measurements can then be used for a CB. An update to the draft is planned to address comments and gorry will work (as Editor) with David (as Shepherd) on sorting this. --------------------------------- 5. SCTP draft (moved from Monday) 5.4 Karen Nielsen - SCTP Tail Loss Recovery (15 minutes) draft-nielsen-tsvwg-sctp-tlr Karen: There is still work to do on the draft, and we are tracking work in TCPM and QUIC. David: The timeframe for when you'll ask for wg adoption? Karen: Optimistically, we expect to do this at the next IETF. --------------------------------- 8. Individual Drafts 8.1 Tim Szigeti - Mapping to 802.11 (25 minutes) draft-szigeti-tsvwg-ieee-802-11 (presented by Fred Baker) Tim: Renaming the draft prevents the datatracker from showing the diff. Fred: You can use rfcdiff to do this for any URL. David: I can make a "replaced by" change that will add this linkage between the two drafts. Pat Thaler, Broadcom & 802: The mappings in 802.1 are only a suggested default behavior. There is no fixed mapping in 802.1 w.r.t. priorities. Ordering of priorities is totally configurable. Over the past 8 years, we've added a number of other ways to handle priority other than strict ordering. There's more than 1 default mapping for 802.1, e.g., one for TSN (enabling home audio-video bridging, AVB). John Kaippallimalil: There's an additional mapping between IETF & GSMA/3GPP. [Aside from David: See RFC 7561, Section 4.2] Fred: I would prefer 802.1 issues be handled in a new draft. More defaults will be added. Putting everything (802.1 and 802.11 mappings) in one doc would add to the confusion. It would be nice if 802.1 mappings were consistent with 802.11 mappings. Pat: The link speed does make a difference in whether a switch would care about particular traffic differentiation. Any carrier will use priority differently on their own network and have their own mappings. We don't need mappings to be the same, carrier to carrier, we need the DSCP interpretation to be the same. David (to Pat): Do you care about priority settings in home networking gear? Pat: Yes. For TSN there is a suggested default, which is what we expect to work generally within homes. David: In this discussion, do you think there's anything the IETF could usefully do? Pat: Other than clearly defining what the DSCP meanings are, no. Request for working group adoption David: How many have read draft? none. [People had commented to the list, so some people at least must have read this.] David: We need to see a few people read the draft before a wg adoption call. We can ask again on the list. Fred: There has been some discussion of revising RFC4594. Cullen may be interested. We don't intend to make changes to code points or add a lot more of them. The 1st step is to define a triage list of what is needed. Dave: We may also want to write some scoping language; since RFC4594 is very wireline network oriented, it may need some clarifying language. Fred: A question to the wg: how badly do you want this? Dave: It is hard to say without seeing the triage list. --------------------------------- 8.3[new] Nik Teague - DDoS Mitigation (dots) Transport (10 minutes) draft-ietf-dots-requirements draft-ietf-dots-use-cases draft-reddy-dots-transport [Item included to coordinate with the IETF DOTS WG - follow-up activity can be taken to this WG] Aaron: The mitigation provider may be several networks away... Lars: Please read draft-ietf-tsvwg-rfc5405bis when discussing use of UDP. TCP connections age out (you can't just open a TCP connection and leave it, and then expect it to work). Nik: We plan to have a heartbeat. Lars: That generates state. DTLS doesn't work on unidirectional UDP. You need to consider rfc5405. UDP design will be challenging. Bob: How many hosts are sending heartbeats? Millions? The method may form an attack on the mitigation provider. Note that NAT timeouts typically are 30sec. Nik: tbd. Bob: Lots of repeat packets seems a better way than creating many idle encrypted sessions. David: You should do both TCP & UDP. ??? - use case author: an undocumented use case includes on-premise system always filtering traffic. David: Please help the DOTS WG to get this right. Meeting closed.