IETF-90 Transport Area WG meeting, TUESDAY, July 22, 2014, Toronto. WG Chairs: Gorry Fairhurst James Polk David Black 0900-1130 EDT Tuesday Morning Session I 1. Chairs (10) NOTE WELL Charter & Milestones Review Agenda Document Status Charter and Accomplishments 2 IDs past WGLC o RSVP support for PCN o DTLS Encap of SCTP for RTCWEB 1 ID in WGLC o PR-SCTP there is still time for comments at the IETF 2 IDs almost ready for WGLC o SCTP NAT support o RSVP application- ID profiles TCMTF - Feedback summary DART - Feedback & Initial recommendations draft-york-dart-dscp-rtp 2) Chairs - Drafts Under review for publication 2.1) Georgios - RSVP for PCN (No presentation) draft-ietf-tsvwg-rsvp-pcn - IANA update 3) WG ACTION 3.1) Michael - DTLS Encap of SCTP for RTCWEB draft-ietf-tsvwg-sctp-dtls-encaps-03 - WGLC completed. There were 2 new revisions based on WG LC comments. Gorry: The WG milestone has this as a PS draft. Clarifications during WGLC: Added text on ECN, DF, DSCP, PMTUD. Had some security review from Ekr - one issue is which version off DTLS to be used. Gorry: What happens with future spec of 1.3? Michael: We will ask if people are willing to accept the old text? David: Could use a lower case "should" be used to enable the ECN bits to be passed through. David: There is an ICME text on min workable MTU, please check this. David: There are multiplexing issue that gives QoS issues relating to DART. Michael: We have port numbers on this. WG Chairs. The Chairs Will review next version with updated security text and see how best to progress this: A second WGLC may be needed if the final document is significantly different to the ID that was WGLC'ed. 3.2) Joe - Recommendations for Transport Port Uses (5 - no presentation) draft-ietf-tsvwg-port-use - Post WGLC update This is charted as a BCP for people requesting port numbers from IANA and how to use them. The document got feedback on the list with questions about the intended audience, recommendations, etc. A new draft is being prepared to address this. Gorry: When the revised ID is submitted it is hoped that it will incorporate changes to address key issues and the chairs will then confirm the intended publication type with the ADs. A further WGLC will be needed prior to requesting publication of the draft. 3.3) Michael - SCTP PR Policies draft-ietf-tsvwg-sctp-prpolicies - WGLC in Progress, there had been discussion on the list. No further comments at this meeting. A new ID will be needed at the end of WGLC. Gorry: SCTP PS documents have traditionally had an Informational API section. This is normal for these specs. Karen: I have other comments on the base spec, which we can discuss on the list. Please send comments to the list. -------------------------------- 4) Working Group Drafts 4.1) Michael - SCTP head of line draft-ietf-tsvwg-sctp-ndata Jana: I like the idea of "interleaving": How can HOL blocking be reduced using this? Michael: It's a receiver API design that needs support at the receiver. Jana: Can we state how this benefits? If we do not do partial delivery. Michael: Both slides needs to use the new data chunk. Jana: Can we explain the use-case and explain this. David: Can we make the name more descriptive than "New" data? Michael: Yes we need a new name? Gorry: Ideas for a new name? Karen: I-data for "Interleaved" data. Gorry: Any other ideas? (none) Michael: This seems OK, but we need to decide finally Gorry: Please send to the list and confirm there. 4.2) Randy and Michael - SCTP NAT Support - Discussion of single draft to replace: draft-ietf-tsvwg-natsupp draft-ietf-behave-sctpnat Combined draft on schedule for November 2013. 4.3) Karen - SCTP Failover draft-ietf-tsvwg-sctp-failover Gorry: How many people had read this? (4+Chairs) How many people could also volunteer to review? (3) Gorry: Please ask for more reviewers to prepare for a future WGLC. Michael: I think Linux has some kind of implementation of this? David: Please ask the Linux development community if they have any feedback on the latest version of the draft with respect to what was implemented. Karen: And what happens if there is no feedback? Gorry: There there is no additional review comments, and the document from this WG stands. We need anyway to answer such questions when we write this up for publication, asking now keeps things simple. 4.4) Cullen - rtcweb qos draft-ietf-tsvwg-rtcweb-qos Michael: Do you have different DSCPs in the same 5-tuple? Cullen: You can have to different endpoints. To the same endpoints this is the problem of DART. Michael: Are you saying that multiple data channels with different priority? David Black: A short answer is: don’t do this because any re-order of packets will cause trouble to SCTP. Please do not mix DSCPs on an association and this will impact CC - since these can be reordered, Cullen: OK we will not combine different DSCPs on the same CC Michael: This makes me happy. If you did use more than one DSCP within the same Association you would then have needed a load sharing mechanism - to be defined - to do this. Justin B: The 2-dimensional nature of the table implies a hierarchy. Could we have more than one channel? How do browsers know which one to use? Fred: The AF numbers are not ranks (ordered), they are treatments not priorities. The committed rate may be large compared to the excess rate (AF42). You can get something quite different to what you expect. Is the expectation that the data is handled differently because it is video? David: Provisioning is AF3x not at individual levels. This uses multiple queues, but it depends on router vendors. EF is quite different in the way it can be configured. : Can we sync the audio and data? David: This coordination in belongs in RTP David: CS1 is "less effort" and seems quite a different treatment, and can result in significant priority inversion. Cullen: We tried to explain that CS1 may mean default, but you can get priority inversion. David: What do you Fred: CS1 can be a low-quality of service. It does what it was designed to do? Al: The operators would prefer to see this as informational, they will have a hard time seeing this on standards track. There seems to be a new different way of doing this? Cullen: We want the audio and video to be dropped into the same queue. Many people want to do multiple levels of data? Al: You are trying to make something here that is new. Cullen: The draft should also mention RTCP - probably make this the same as the flow - we probably should say this. Michael Welzl: This blends priority between endpoints and between a browser, the latter is something that can be handled by coupled congestion control. Cullen: What happens if EF class has excess traffic. Fred, Drop, please check RFC. David: RFC2474 defines - default forwarding - which could be abbreviated "DF". Gorry: This just need an introductory block of text. I am also really unsure about reusing the abbreviation DF (otherwise used for Don't Fragment) and wonder whether we should simply refer to this as the forwarding offered by the BE service. Karren: This draft is about how you may want to mark things, but be clear about relative markings and the DART drafts need to say what is safe. Matt: Please don't include the mappings in the document, but do include references to them. 4.5) Ed/Lucy - GRE in UDP draft-ietf-tsvwg-gre-in-udp-encap I think IPv4 implementations should set the UDP checksum to zero. David: My usual case would be to suggest MUST be set, but then we hear that this isn't possible in this case. Can we live with MUST implement the ability to provide a UDP checksum? Puneet: The implementors do not plan to implement the checksum anyway. You can not expect overlay UDP checksum using original data packet UDP checksum. Eric: We have documents that allow use IPv6. Gorry: You need to provide a spec of how the IPV6 zero checksum mechanism is implemented. David: This is a design spec, and tells you what you need to do to implement this. Eric: OK. David: There is text this morning from Adrian that may help with defining places where this is safe to use. Lars: I think this is going in a good direction. Fred: I would ask what do you mean by CC? - : Does it say use the IPv6 flow label for entropy? Lucy: Yes. Gorry: CC is probably the wrong term - this is more a transport circuit-breaker mechanism. X : If IPv6, then the FL could be used? Lucy: Yes. 5) Individual Drafts (requesting adoption) 5.1) Ruediger - Diffserv Intercon draft-geib-tsvwg-diffserv-intercon Fred: I understand this slide deck. Al: The complicated picture provides a motivation for operators to use common code points which is good. You can't do this for every link type, this will require some help. I support this for adoption. Mike B: I understand the problem. The tunnelled traffic is described, the non-tunnelled packets have the same problem? David: Yes, Mike : Non-tunnelled v. tunnelled you have the same problem. David: Yes. Mike: Is there any intention on suggesting a high medium and low levels. Chairs: Is this a topic we think TSVWG should work on? (Hum for, none-against). We expect a new version and expect to see this discussed on the list. 5.2) Lars - UDP Usage Guidelines bis draft-eggert-tsvwg-rfc5405bis How many people have not read, but plan to read? (6) Need more reviewers (Jana and Brian volunteered) Chairs: Is this clearly scoped, and should we work on this topic? (hum for) Is the scope unclear, or people think we should not work on this? (none) Please read, we plan to make an adoption call before Hawaii. 5.3) Gorry - Transport Circuit Breakers draft-fairhurst-tsvwg-circuit-breaker Chairs: How many people have read? (10) How many people have not read, but plan to read? (15) Is this clearly scoped, and should we work on this topic? (hum for) Is the scope unclear, or people think we should not work on this? (none) Please read, we plan to make an adoption call before Hawaii. 6) Individual Drafts 6.1) Xinpeng - Tunnel Congestion Feedback draft-wei-tsvwg-tunnel-congestion-feedback - Updated simulation and congestion feedback David: Thanks for doing this, this is a good direction. But it need details. It does not really surprise me that the tunnel behaves like a link. Lars: I haven't seen this before - this looks a lot like CONEX. If you used something like CONEX would this be different? Xinpeng: This is similar but one step simpler. Lars: There was a lot of work in the '90s were the RTTs were the same that showed this was bad - where the two control loops fought for capacity. Is it possible to find negative interaction? Matt: Users experience congestion control for congestion that they did not create, so this is a side-effect that may be undesirable. Is this something that the operator may wish to apply to control their multiplexes. Xinpeng: Yes, the gateway is responsible for controlling the aggregate. Fred: There are cases where the upstream is traffic-engineered. It would be interesting to know if the upstreams are congested. Gorry: how many have read the latest draft? (1 hand) Gorry: WG please read the draft. --- 1300-1400 EDT Tuesday Afternoon Session I 7) Chairs Meeting 2 NOTE WELL 8) Individual Drafts (continued) 8.1) Norman - Differentiated Service Class Recommendations for LLN Traffic draft-svshah-tsvwg-lln-diffserv-recommendations - Time Synch; reservation control; convergence; ease-of-use. Industrial (server to factory floor), Vehicles, AV production with 10^10bits per session (802.1) Erik Noordmark: Is the L2 network connected via L3? Norman: Yes, in some cases. Toerless: Have you done an analysis of what is available? Norman: We are here to look at this. 8.2) Deterministic Forwarding PHB draft-svshah-tsvwg-deterministic-forwarding No questions. 8.3) Dan Wing - TURN Flow Data draft-wing-tsvwg-turn-flowdata - Relevant to the TRAM WG : Is it possible you could redirected on this field? Dan: Yes, it could be based on what the Turn server is able to support. David: Is there similarities here to the RTCweb classes. Dan: This is not setting DSCPs - they may mean different things in the two parts of the TURN network. : RTCweb has 4 different levels. This seems to have 27 combinations. Mapping to 4 points may be problematic. Dan: as ever that has to be done. Gorry: Do discuss the QoS aspects of this problem on the tsveg list, and when we get to that point we could decide how or whether to progress and do the TRAM-oriented signalling. 8.4) Karen - SCTP Tail Loss Recovery (no draft yet). Alex: Does this different approach also apply to TCP? Karen: Yes, we wish to achieve the same, but we did a clean start. It is applicable to TCP. Our plan is to add a supplement to do this. The TCP proposal is more of an update, we do things like FACK, but use s state algorithm. Michael: I like the work. This also applies to RTCweb. 8.5) Michael/Gorry - ECN Manifesto draft-welzl-ecn-benefits David Black: This should be in either TSVWG or AQM WG. Lars: It could also be an IAB document, since it offers very general guidance on the architecture. David: We'll discuss how and where to progress this with the ADs. Please read and comment on these new drafts on the list: * Rachel - Traditional TCP Problem Statement draft-huang-tsvwg-tr-tcp-ps-00 * Deng - QoE Evaluation for HTTP Adaptive Streaming draft-deng-tsvwg-qoe-evaluation-has -End-