AGENDA for TSVWG Meeting at IETF 99, Prague, Cz WG Chairs: Gorry Fairhurst, David Black and Wes Eddy Note Taker 1: David Dolson Jabber Scribe. Session 1: 13:30-15:30 Tuesday Afternoon Session I - David Black discusses status slides - There is an open issue and significant changes are going to be required. Spencer Dawkins (AD): I like the Chunk draft. What does the ECN experimentation draft need to say? David B: ECN makes the NS historic. The new text will remove the IANA registration for TCP NS field. Gorry: When will this revision be ready? David: Next week. Spencer: The ECN draft is a 3GPP dependency. David: The SCTP n-Data draft is the last of the webrtc drafts. Bob Briscoe: There will be another dependency for an AD action wrt to a document status change. David: Spencer has an action to do a status changes document fro ECN-Nonce. Spencer: OK, thank you. Public humiation works. David: The PHB LE mappings are stable; I hope to resolve and send to last call. David announces WG the adoption of the FEC framework drafts. These do not justify a new wg. Gorry: Please talk to Gorry if interested in transport-header-encrypt or PMTUD drafts. David: TSVWG'ers please also go to intarea mtgs for Tunnel MTU, MPT or SOCKS documents. Gorry: Or speak-up to Chairs or mailing list if you think there are Transport issues for these drafts. 1. Review Agenda (WG Chairs) - No agenda changes 2. Status/updates (WG Chairs) 2.1 Tunnel Congestion feedback draft-ietf-tsvwg-tunnel-congestion-feedback --- WGLC more work needed. David: This needs significant work to frame an example use. 2.2 ECN Experimentation draft-ietf-tsvwg-ecn-experimentation --- WGLC concluded. David: This will be updated to addresses the IANA issue. 2.3 SCTP I-Data draft-ietf-tsvwg-sctp-ndata --- WGLC concluded. 2.4 DS IEEE 802.11 — WGLC Summary draft-ietf-tsvwg-ieee-802-11 Tim Szigeti talks to slides - The 802.11 mapping is already in wide use in Cisco & Meraki APs and Apple devices. ~800M devices using recommendation. - We will avoid the overloaded word "trust". - The LE PHB PS will obsolete RFC 3662, and thus have a cascading effect on RFC 4594 and also this PS - Please review. David: Depending on consensus on the DSCP decided for LE, the WG may reference the LE mapping, rather than update this document. 2.5 UDP Options - Adoption draft-ietf-tsvwg-udp-options Tom Jones: I have a working implementation in FreeBSD; I would like to interop with other operating systems. David Dolson: Was the old FreeBSD code OK for receiving datagrams with UDP options? Tom Jones: Yes the recieve code was safe. 2.6 Related work that may be of interest: draft-fairhurst-tsvwg-transport-encrypt draft-olteanu-intarea-socks-6 draft-lencse-tsvwg-mpt draft-fairhurst-tsvwg-datagram-plpmtud 3. WG Drafts WG Drafts - Diffserv 3.1 Roland Bless - LE PHB draft-ietf-tsvwg-le-phb Roland does not think 2 DSCPs are required for LE. 3.2 Chairs - Discussion on appropriate DSCP for LE - Short reports on observed remarking behaviour for proposed LE DSCP (please contact chairs) Raffaello Secchi presented a study about DSCP LE codepoints using PATHscope & Edgetrace. DSCP 2 might not be good because of bleaching of upper bits in deployed networks. Many other DS classes would be mapped to LE. This effect is worse than mapping to best-effort. 16% ToS bleaching or 4.7% ToS bleaching in different scenarios. Fred Baker: There are 8 values with top 3 bits set to zero. The odd values are for local use. Gorry: Half of these are local use, the registry says the other could be allocated by IANA if the IETF has need. Fred: The value we would like to have in the upper 3 bits is 0, so this might allow a DSCP of 2/4/6. I do not see the real difference. I would rather tell people not to bleach the DSCP. Gorry: This advice to people configuring routers is still correct. Tom Jones: SSH is using code point 2 and 4, one for bulk transfer, one for the rest. This is squatting on the code point. David: It would be good for someone to fix that, but it is not what is steering this decision. Michael: Is the bleaching only to zero, or to other values as well? Raffaello: There is beaching to zero, but that is not the issue. In this case the dominant pathology that impacts this decision is ToS bleaching, and a small number of other DSCP changes unrelated to original values (i.e., operators assigning all traffic to a specific DSCP). Michael ?: This is probably not intentional remarking. Brian Trammel: It looks like DSCPs are used inside the network, but they could leaks out. Brian: How many ASes were traversed by measurements? RS: 30 in these tests. Brian: So, we're talking about 10^-4. Can we just make phone calls to the ASes with broken routers? David Black: IANA registry: code points in pool 3 ending in 01 may be utilized for future standards allocation. Gorry: I have a question: Is this going to be better than CS1? Rolan Bless: The term "IP precedence bleach" is more accurate. We should stop working around broken configurations/implementations. Why is SSH broken? David: On Michael's comment, operators might not be clear on what config their equipment is doing. David (Chair): Can I see a show of hands straw poll: how many think they understand the issue? (About a dozen). David (Chair): How many think we have enough info today? could we stick with DSCP 2 or pick an odd-numbered one? How many people who understand the issue think we have enough info to make decison now? No hands raised. Bob Briscoe: It could be a mix of "No" and "Not sure". David: The lack of raised hands is important. Roland: The odd code points would be worse than 2, given ToS precedence bleaching. David: The reason to not choose 2 also applies to not choosing the other DSCPs. Tim Chown: We do not know if people will fix their configurations. Why did we pick 2? David: The even numbered code points are for standards action; others for local use. Tim Chown: I am inclined to go with codepoint 2. Brian Trammel: I did not raise my hand. Did you do Pathscope measurements for 1 and 5? Tom: I have Edgetrace results for DSCP 1 that show this is as expected. Gorry: PATHspider shows 1 gets thru network. Not bad from traversal point of view. Brian: For the SSH problem, can we just do a pull request in SSH code? Tom: Yes. However, the pull request is ~12 years old. They will probably never take it. Tom: The ToS precedence bleaching behavior is the same as for 2 but without the peril of 2. David Black (Chair): We cannot make a decision now. We will follow-up on the list WG Milestones Review Tim: The 802.11 milestone should be noted as "Proposed Standard", not Informational. David Black: This is a typo - we will fix. Gorry: I would like more info on the LE DSCP from peoplw. Raffaello, can you do more measurements? Raffaelo: Yes. Gorry: Let's get to the bottom of it. Speak to Raffaello if you also wish to make measurements of DSCPs. David: Can get NAT support publihsed by the End of Year? (yes) David: For L4S? Bob: Maybe fix a milestone before Sept. 2018. Essentially the drafts are finished, except TCP-Prague; the drafts are in holding pattern. Gorry: We can do an early WG last call to get consensus, even if we freeze and do not immediately publish. David : UDP Options -- We are waiting to hear about implementation work. David: Is June a possible milestone date for the FEC drafts? (yes) WG Drafts - ECN 3.3 Bob Briscoe - Guidelines for Adding Congestion Notification Propagating ECN Across IP Tunnel Headers draft-ietf-tsvwg-ecn-encap-guidelines We want New Radio to support ECN? And therefore L4S. David: This also came up at 3GPP liason meeting. (see Liasion slot in TSVWG on Thursday.) David: We hope to have published very soon. draft-ietf-tsvwg-rfc6040update-shim This exists so the IETF community can update other proposed standards. Bob: In Problem#1 slide the figures are wrong. Bob: "NSH" is vague, not applicable. Bob: We did not (yet) find any evidence of automatic configuration of GRE. Gorry: Does anyone in room know cases where GRE is automatically configured? e.g. in VPN usage? Brian Trammel: If BANANA is chartered, a new automated GRE tunnel setup might show up, at least we have this list to start from. Jake Holland: AMT RFC7450 is missing from list. Bob: I will look. We only need to know about shim-types. Christian H: Is it conceptually hard to handle ECN in Teredo? (No.) If we specified it, would it be updated? Dave Dolson: Do I understand this is about finding inner header after the Ethernet E.g., in CAPWAP? Bob: We need to propagate both ECN and CE across layers. Christian: In Teredo, an operator is not exactly the end-user. WG Drafts - L4S Gorry: We need people to activity participate in these L4S drafts - please comment on list, especially on the architecture ID. 3.5 Bob Briscoe - L4S Internet Service: Architecture draft-ietf-tsvwg-l4s-arch 3.6 Bob Briscoe - Identifying Modified ECN Semantics draft-ietf-tsvwg-ecn-l4s-id ECN is used as a default classifier, but there may be other classifiers. E.g., ECN combined with other fields of traffic (e.g., IP address). Adding hooks in Linux to let people add other classifiers. But advantage of the default is it being end-to-end eventually. David Black (from floor): DSCP classifiers help an enormous amount for incremental deployment. Bob: The more identifiers you add to the classifier, the less incremental the deployment can be. Bob: There are business motivations... David: Some wording changes should be added to the draft to indicate it is optional. Andrew: We cannot see how to test without other classifiers. So if we do not add it, someone else will. Some people are still using the entire ToS byte for load-balancing. This is not best practice. Gorry: This is something people have to fix. David Dolson: In suggest putting ECN-bleaching (or otherwise bad behavior) in tools like traceroute, so we can measure this easily. Andrew: There can be reordering when entire ToS field is still used for load-balancing entropy (e.g. ECMP). Multiple router vendors have support for both currently specified methods and the legacy byte-based methods. Many devices still have wrong defaults. These need to be updated. 3.7 Koen De Schepper - DualQ Coupled AQM for L4S draft-ietf-tsvwg-aqm-dualq-coupled Gorry: BBR isn't in any working group. But we should of course pay attention to what is happening in the real Internet. Koen: Please test and try. -------------------------------------------------------------------------------------------------- Session 2: 18:10-19:10 Thursday Afternoon Session III 4. Agenda recap (WG Chairs) Note Takers: Roland Bless & Dave Dolson Liaison Notices (WG Chairs) Georg Mayer No clear view on requests for 3GPP, still building up the requirements for 5G. Question in Q&A about whether someone wanted to not consider ECN in 5G, then please tell me, I haven't seen things. ECN will be in 5G. We will come and speak when any questions arise in 3GPP that are relevant for this group. Spencer (AD): Thank you for coming to talk to us. 5. WG drafts - Transport Protocols 5.1 Michael Tuexen - SCTP NAT Support draft-ietf-tsvwg-natsupp Gorry: Let's try to put IPv6 into this document and see what happens. This should be ready to WGLC soon. 5.2 Michael Tuexen- RFC 4960 Errata and Issues draft-ietf-tsvwg-rfc4960-errata Gorry: Can you remind us about the standard status of related RFCs (6096, 6335, 7053)? Michael: There are no new features, just clarifications. David B: Are we referencing the RFCs or copy/pasting? Michael: New text from the SCTP dependencies, but citing normatively the BCP on IANA procedures. Michael: There is an opportunity to go for Standards track and progress to Internet Standard. Gorry: This document will provide a check list of changes for Spencer that needs to be reviewed. Spencer: The process for progressing to full standard is OK with me. Gorry (as Chair): Does anyone think we're missing anything in SCTP? (no one answered) 6. WG Drafts - FECFRAME 6.1 Vincent Roca - FECFRAME draft-ietf-tsvwg-fecframe-ext 6.2 Vincent Roca - RLC FEC Scheme for FECFRAME draft-ietf-tsvwg-rlc-fec-scheme Vincent: I am unclear whether we should add one or two more extensions, e.g., also could consider sparse versions. David Black: It is good to see that Marie-Jose did reviews. Others, please do comment on the list. Vincent: We hope to get more reviews from the network coding RG. I already asked them. Jake Holland: Are there implementations available? Vincent: Yes. 6.3 Michael Tuexen - UDP Encapsulation of SCTP draft-tuexen-tsvwg-sctp-udp-encaps-cons Gorry: I confirm this process. This document will die, and the working will consider adoption of the document that replaces this. Jake Holland: Was the decision to change the heartbeat based on measurements? Michael: I just looked at what other protocols do (15s). Also applications can control this. Gorry: Should refer to the UDP Usage Guidelines BCP. Michael: OK. Gorry: please comment on the list: - Please make measurements and have thoughts about the effect of LE codepoint selection. - ECN encaps and shim have been talked about a lot at this IETF, they may be ready soon to progress. - L4S arch needs eyes from anyone who has interest in ECN and L4S in particular. - Please read SCTP rfc4960-errata if you have intrest in SCTP.