IETF-100 TSVWG Meeting Monday Afternoon session Notetaker: Brian Carpenter (thanks!) 1. Chairs: The chairs presented the WG slides, noted completed RFCs, milestones, etc. RFC's completed: draft-ietf-tsvwg-sctp-dtls-encaps draft-ietf-tsvwg-sctp-dtls-ndata (I-data) Other WG drafts: draft-ietf-tsvwg-ecn-experimentation (post IESG, will be at RFC Editor soon) draft-ietf-tsvwg-ieee-802-11 (IESG) draft-ietf-tsvwg-tunnel-congestion-feedback (work needed) draft-ietf-tsvwg-udp-options 2.Individual drafts: 2.1 Note detnet WG discussion of draft-thubert-tsvwg-detnet-transport (in detnet WG) 3. ECN encapsulation (Bob Briscoe) draft-ietf-tsvwg-rfc6040update-shim draft-ietf-tsvwg-ecn-encap-guidelines Bob reviewed rev -05 of Propagating ECN across IP tunnel Headers Separated by a Shim David: We expect to progress the tunnel and shim encapsulation drafts together. Bob Briscoe: January would be a suitable milestone for both drafts. People willing to review these drafts: Joel Jaeggli Stuart Cheshire 4. LE PHB, round 1 (Roland Bless) draft-ietf-tsvwg-le-phb One serious open issue remains: DSCP selection, since issues had been raised on the proposed code point of DSCP 2 voiced in Prague. Gorry reviewed the discussion in Prague and asked the WG to consider the options and be ready to make a recommendation by the second meeting. Brian Carpenter: One of the characteristics of Pool 3 is that it currently is permitted for local or experimental use. Gorry: Yes, and if such an operator understands how to use Pool 3, then they could be expected to know how to remap that at the network boundary. It may of course remap this to zero. Bob Briscoe: Is marking up to zero OK really OK? Gorry: Roland's draft says you should also use a LBE transport to protect the Default traffic. Andrew McGregor: We have networks that provide a LE code point and cases where LE and BE traffic has to share a queue, and the use of a LBE transport works fine in that case. 5. Individual ID (Colin Perkins) draft-fairhurst-tsvwg-transport-encrypt The draft had been presented in OPSEC and there was interest from there in a document on this topic. Lars Eggert: QUIC is working on a protocol that has encryption. There is a design team to consider whether there is a need for information to help operations. What happens if this work concludes something different to what QUIC decides to do? QUIC is on a short schedule. Colin Perkins: QUIC is on an accelerated plan that is not taking as much input as it could. This is a consideration for the IETF. David Black: If QUIC is the first example, then attention should be focused there. Colin Perkins: The draft is about what needs to be done and not what needs to be changed. Lars Eggert: I am concerned the IETF-QUIC will be blocked if nothing happens. That is a concern if the IETF QUIC is not progressed, while we wait for an outcome here. Spencer (AD): This document is targeting informational. It seem crazy to hold other WG work on the basis of an informational draft. What is the intended audience for this draft if not QUIC? I think it is brilliant and we should have been working on this all along. I want to be sure the document is useful. Brian Trammell: I edit the QUIC manageability of the document that specifically addresses the concerns wrt to QUIC. I really think it is useful to have a document that targets the transport issues. This approach on looking at the impact of the people in this room may be a way to make progress. I think the insights here need to get into the other drafts. I assume you have looked at the things that are relevant in other documents at the IETF? Colin Perkins: We think we have looked at these (we may have missed some - if we have let us know.) Flemming Andreas: I agree with the message here. Roni Even: I support this document, we need to balance security and manageability. Joel Jaeggli: I am largely sympathetic to end system protection from meddling, but also have to protect endpoints in scalable ways from devices that just send packets. Lars Eggert: The integrity protection part is a part, but also the ability to prevent middleboxes ossifying on the stack. It would be good to know what operators think are needed. Colin Perkins: The trade-off is whether some ossification is good or bad. Not changing some parts indicates success - we need to decide carefully what we expose and what can change. Some forms of ossification are actually good. Mark Townsley: The cat-and-mouse game to figure out what is needed is a race to the bottom. We should step back and work out what needs to be exposed. We need to figure out the right data to expose for the correct reasons. WG Chairs (David): Please continue to read the draft and discuss on the list. ------------------------------------------------------------------------- Friday Morning session Notetaker: Stuart Cheshire (thanks!) 6. Agenda Part 2 6.1 Chairs slides The SCTP ndata ID has now been approved by RFC-Ed. Revision -08 of ECN Experimentation was announced 2017-11-13. The chairs do not expect new issues, but ask the WG to please confirm the final text is correct- there have been changes since WGLC. (gorry will remind people on the list). Please review changes by 23rd Nov 2017 6.2 AQM: draft-finzi-priority-switching-scheduler (Fred Baker) This is a proposal is to make elastic traffic more predictable. The chairs confirmed this is the appropriate WG to discuss AQM. Please discuss this ID on the draft to find out if there is interest, operational use, and what people think is appropriate to do with this draft if it is taken forward. 7. SCTP (Maksim Proshin) draft-tuexen-tsvwg-sctp-udp-encaps-cons No change since last IETF. draft-ietf-tsvwg-natsupp No change since last IETF. draft-ietf-tsvwg-rfc4960-errata Revision -03 incorporates the remaining known issues. Chairs: Is there anyone who can look at the Linux implementation to see if there is any feedback. The chairs will ask for reviewers on the list, please tell the chairs. Once we a list of reviewers the WG plans to start a WGLC. (Started after the meeting.) 8. L4S (Bob Briscoe) draft-ietf-tsvwg-ecn-l4s-id draft-ietf-tsvwg-l4s-arch These drafts have not been significantly changed. There had been progress with 3GPP in clarifying the operation of ECN, but a proposal to add ECN support to RLC was not taken forward in release 15. There is intention to retry for release 16. draft-ietf-tsvwg-aqm-dualq-coupled The document will be updated to include experiment considerations. David Black (from the floor): I am interested in how a dual-queue structure relates to DiffServ, and whether there would be multiple instances of the queues matching diffserv aggregates. Michael Welzl: Is there a simple way to specify the AQMs that can fit within the framework? Bob: Yes this is the intention of the architecture ID. An update is planned before IETF-101. 9. LE PHB, round 2 (Roland Bless) draft-ietf-tsvwg-le-phb Measurements from Aberdeen University showed that the group needed to consider other traffic aggregates that may be mapped to DSCP 2. Roland provided an update on the draft, and will propose a new DCSP choice. The WG will consider a process draft to allow DSCP allocations for standard PHBs in Pool 3. The LE PHB draft will have to wait for that in order to allocate a Pool 3 DSCP (both DSCP 1 and DSCP 5 are in Pool 3). Brian Carpenter: I have sympathy with this request. I think routers that do what the architecture requires will be OK. I think a standards document (PS) update is needed to over-ride the current allocation method. I assume this is standards-action? Gorry Fairhurst: Yes, It would be standards-action. Do you think we should reserve DSCPs 1 and 5 for IETF assignment, or should we grab the whole pool? Brian Carpenter: I think this should change assignments for the entire pool. David Black: I think we should try this approach for the entire of Pool 3. WG please tell us whether a DSCP of 1 or 5 is most suited. Will add text that relates to the draft-ietf-tsvwg-ieee-802-11 (based on running code) and possibly updates that RFC-to-be, to be decided. [Clarification: the text to be added to ietf-tsvwg-ieee-802-11 now is to state that a new DSCP is being assigned - that draft will not wait for the assignment to be performed.] 10. FECFRAME (Vincent Rocca) draft-ietf-tsvwg-fecframe-ext draft-ietf-tsvwg-rlc-fec-scheme David Black (individual): The density parameter is currently specified linearly, maybe an exponential encoding may provide more dynamic range? Vincent: OK, I understand, Both documents could be ready for IETF-101 or shortly after. Please discuss on the list. New drafts to be considered by the WG: 11 draft-fairhurst-tsvwg-datagram-plpmtud (Gorry Fairhurst) The draft had briefly been presented in INTAREA at IETF-100 and there seemed interest there in TSVWG doing work on this topic. Authors requested working group adoption. Mikael Abrahamson: This is a real problem. Do we know how many TCP hosts use PLPMTUD? Can someone find this out - it is interesting to know if hosts have PLPMTUD enabled by default. Maksim Proshim: I support this work, there are issues in this area. What do you do with data packets sent with the wrong pmts? Gorry Fairhurst: This depends on the transport, so that's not our responsibility, but we do say how to handle the probes. Maksim Proshin: It's hard to re-fragment for SCTP. Gorry Fairhurst: Indeed, speak to the SCTP people - also see the end of the draft for other issues. Vincent Roca: I support this draft, and have done some work surveying PMTU. Bob Hinden: I support this work, we should have done this before. Have you thought about DNS/DNSsec? Gorry Fairhurst: I heard it may help - I do not know DNS, so anyone interested in this please talk to me about how to do this. Mikael Abrahamson: Is this for the UDP apps developer, OS? Gorry Fairhurst: Could be done in UDP options in the stack (keeping the same 5-tuple); could be added to an IETF transport; could be done in the app. M Abrahamson: Applications may wish to be involved. Spencer Dawkins (AD): Applications have deployed really conservative packet sizes to ensure the paths work. It may be good to talk to the apps folks about what happens when this is deployed. Chairs (David Black): Please raise hand if you have read the draft (few). Please hum if you think TSVWG should adopt this draft (hum for). Please hum if you think the TSVWG should not adopt (none). Chairs (David Black): We will start an adoption call on the list. 12.draft-han-6man-in-band-signaling-for-transport-qos (Lin Han) A proposal for a sub-transport layer for IPv6 that can provide QoS, path-aware routing that can take advantage of advanced hardware router functions. Targets apps needing high capacity or low latency. The work has been discussed in ETSI Next Generation Protocol. Gorry Fairhurst: When do you expect the ETSI NGP project to complete? Lin Han: This work time may be ready by the end of the year. Gorry Fairhurst: Is there more than one work item? Lin Han: Yes, this is one of many items. Roland Bless: I see issues at various levels. It seems you do not pass the resource messages with the data. Lin Han: We try to reduce the complexity compared to RSVP. The network can release resources if they are not used (e.g., up to 8 seconds). We have security mappings and can authorise the users. Michael Scharf (relayed from Jabber): Please see RFC 6077 that describes many of the issues that need to be considered in such designs. Mikael Abrahamson: There is a business model concern here. Do you want to work across multiple domains? Lin Han: We currently only look at one single domain. David Black (as individual): This seems scoped to a single operator domain. Is there an incremental deployment method? How will this behave if part of the network does not support this? Lin Han: This is simpler than ATM. The source knows if it works. David Black (as individual): This looks like a single operator "walled garden" design. Bob Briscoe: I have read the draft, and do not think there is discussion of layer 2 elements or tunnels. Lin Han: There are other issues with more complexity. This is just a pure IP domain. Chairs (gorry): What are your intentions with respect to this draft? Lin Han: We are interested in liaison with the IETF and to learn. Chairs (gorry): Are the present ETSI documents available to this working group? Please share progress with the list and see if there is interest in the various components that have been presented. Meeting closed.