TSVWG Meeting (Monday - Session I) IETF 109 (Online) November 16, 2020 Agenda Jabber Scribe: Pete Resnick Note taker: Andrew McGregor 1. Chairs Update RFCs completed/in Queue: §RFC 8899 DPLPMTUD (PS) : Document Shepherd: Wes draft-ietf-tsvwg-rtcweb-qos (RFC-Ed: AUTH48) Document Shepherd: David Drafts beyond WGLC: draft-ietf-tsvwg-transport-encrypt (AD Review) Document Shepherd: David draft-ietf-tsvwg-natsupp (with shepherd) Document Shepherd: Gorry draft-ietf-tsvwg-ecn-encap-guidelines (Revised I-D Needed -WGLC Follow-up) Document Shepherd: David draft-ietf-tsvwg-rfc6040update-shim (Revised I-D Needed -WGLC Follow-up) Document Shepherd: David 2. Milestone updates L4S drafts: Milestone date to be reviewed by chairs and draft authors. 3. Announcements and Heads-Up NOTE: Authors of the new drafts below can send ONE slide to be presented by chairs Generic Transport Functions - draft-zzhang-tsvwg-generic-transport-functions. Proposing a general notion of fragmentation, may be applicable to work in other WGs, please read and comment on list. Separation of Data Path - draft-asai-tsvwg-transport-review SCE Update - various drafts HPCC Update - draft-pan-tsvwg-hpccplus PFC - draft-dai-tsvwg-pfc-free-congestion-control 4. SCTP Drafts 4.1 Michael Tuexen: bis update to SCTP Spec. draft-ietf-tsvwg-rfc4960-bis Editorial changes coming, this will remove Appendix A. WGLC is expected December or January, reviews will go to the list after an updated draft is posted. 5. Transport Working Group Drafts: Protocols 5.1 Joe Touch (proxy/remote): UDP Options draft-ietf-tsvwg-udp-options Work is still in progress, a new revision expected after meeting to reflect comments around IETF-108. Once this is posted, please review the ID on the list. 5.2 Gorry Fairhurst: DPLPMTUD for UDP Options (10 mins) - Adoption request by authors draft-fairhurst-tsvwg-udp-options-dplpmtud-03 WG Adoption requested. This needs more people to read draft, the Chairs will take discussion of adoption up on mailing list. -: How does this relate to QUIC? QUIC would not use UDP options to implement DPLPMTUD - it has its own specification in the QUIC Transport ID. 5.3 Greg White: Identifying and Handling Non-Queue Building Flows draft-ietf-tsvwg-nqb - Turning NQB+Default into a PHB Group should be a last resort. - WiFi mapping needs to go to the list. - Items 3&4 on remaining work slide (slide #3) imply that at the edge - : Does one DSCP make sense for access networks and a different DSCP in the core (e.g., backbone networks)? 6. Individual Drafts 6.1 Markus Amend: DCCP Extensions for Multipath Operation draft-amend-tsvwg-dccp-udp-header-conversion draft-amend-tsvwg-multipath-dccp draft-amend-tsvwg-multipath-framework-mpdccp WG adoption was requested. The WG chairs will consult with AD about appropriate next steps for these drafts, including overall approach to work in this area. Wednesday, November 18, 14:30-15:30 Session II 7. Transport Working Group Drafts: ECN 7.1 Agenda Recap & tooling discovery 7.2 Greg White: L4S Operational Guidance draft-white-tsvwg-l4sops Sebastian: I have a comment on slide 3: "reasonable fairness across range of conditions" is what's under discussion. We have currently demonstrated a range of conditions where reasonable fairness is present, but this may not be sufficiently broad. David Black: Where are these tests? In the hosts or a separate test? Greg: It depends. Pre-launch tests for some of it, in-band testing also should be used and is mentioned in some of the L4S drafts. A non-realtime response would be more operational management code. A mix. Andrew McGregor: What kind of granularity would be used for the tests? Per host? Per destination prefix? Greg: One scenario, Residential ISP, you might have a queue on their network so test results could depend on IP address. - Gorry: any operators or vendors here have a quick comment on the single queue 3168 treatment? Andrew: Routers exist that can treat ECT1 as NonECT, but not particular common. - with Jonathan in chat mentioning it's technically in violation of 3168. Bob: It is not formally contrary to 3168; this is not changing the codepoint, it is just being a non-ECN router for that codepoint. Gorry: RFCs have specified different treatments based on ECN, e.g. PCN also specified a different use of ECT(1) (RFC 6660). Jake: I though RFC 8311, did that and placed some requirements on the behavior. Isn't that why it was standards track? Greg: It opened the door to experimental treatment documented in an experimental RFC. David: RFC 3168 permits drop instead of marking, so configuring that is compatible. Jonathan: This draft is requiring networks to be specially prepared for L4S traffic, right? Greg: This is overstating it. These RFC 3168 single queue implementations are known to exist. Deployment prevalence not known. The impact of them existing is not catastrophic. The point is to make networks in general prepared for L4s. Jonathan: Long-running flows sharing a queue can suffer ... also what about tunnels encountering an AQM? Greg: Yes, as mentioned on the slides there is an asterisk there as known point to make with this draft. Jonathan: Risk analysis needs to consider both prevalence and severity. Greg: I agree. Stuart: Apple enabled ECN several years back. I wish we had the problem today of deployed legacy routers doing smart queueing instead of tail drop, but iphone data shows 0 deployment of RFC 3168 marked packets, to many decimal points. Jana: +1 to adopting this. Jake: See our presentation at interim MAPRG meeting. We saw several ASNs that had non-zero CE marking. This had different vantage points than iPhone data, but zero percent is not what we saw. https://www.youtube.com/watch?v=1326B7YYwLM&t=1h12m19s https://www.ietf.org/proceedings/interim-2020-maprg-01/slides/slides-interim-2020-maprg-01-sessa-latency-aqm-observations-on-the-internet-01.pdf Stuart: If you have newer data (ours if from a year or two ago). When we first collected we saw some plausible CE marking (Argentina? France?) which turned out to be bogus -- wasn't actual working smart queueing. If there's measurement of actual working ECN then that would be important to know the prevalence. Jake: We noted that. There were other networks. By country, it is hard to see patterns (?)... on a network basis we do see plausible marking. Bob: Was that single queue, or FQ? fq-codel sees some deployment in recent years. We need better tests to distinguish this. Wes: The chairs plan to start an adoption call for the next revision, please discuss this on the mailing list. The chairs asked how many had read this draft: 15 read it, 19 has not of 88 participants (at the time of the poll) 7.3 Bob Briscoe: L4S ECN drafts (30 mins) draft-ietf-tsvwg-ecn-l4s-id draft-ietf-tsvwg-l4s-arch draft-ietf-tsvwg-aqm-dualq-coupled Jana: What is the intent here, are you asking for last call? The biggest issue seems to be #16 (classic competition), correct? Bob: Yes, that and whether a CC is up to speed with the aspirations in this draft? Jana: At a high level, this seems ready for an experiment. We need to outline what we measure and what we expect to see as part of the experiment. Jana: If the concern about competition with classic ECN is an issue, it is only an issue of L4S is successful. I would like it to become an issue and for L4S to be successful, but needs to be deployed to make that. Colin, Richard, Mirja, Ingemar, Philip, Mark, Koen: +1 (in chat) David: The path to address the safety concerns runs thru the operational considerations draft. Gorry: When this is adopted, is the WG ready to start a WGLC? Do we need something specific? David: I am not sure. We now need to judge as a WG whether there is a reasonable approach to dealing with RFC 3168 "old" equipment. Sebastian in chat: I do not think L4S is ready. Jonathan in chat: I also do not think L4S is ready. Jake: I do not see why an RFC is needed to perform an experiment and report observations, many lab things have been done already, and they demonstrate problems. Colin: I do not think we need to wait for the ops draft. Lars: I am struggling to understand what the experiment is. The draft seems to describe a spec, but not an experiment that tells whether it succeeded or not? Mirja: The problems that were detected in a lab make assumptions about deployment. By deploying it at scale we can find out whether these are really problems at scale or not. Lars: So, the experiment is to throw it on the network and see what happens? Koen: The intent is to get this nailed down, so that CC development engagement can proceed. We should not wait, we should start this, so that more people will work on it. Jana: I think Lars's question is about what is the experiment? History has shown just getting this ECN marking deployed is a pretty big experiment. But, yes, encouraging endpoints to experiment with congestion controllers. Jana: Do we think that by keeping it as a draft in the WG we gain anything? Sebastian: The operational safety seems unproven. Deploying it is un-cautious. I think we should not be talking about last call. We do not have data for a wide range of topologies: we are discussing in the abstract when many people have not examined the data. Greg: The specification of classic ECN is 20 years old, with near 0 deployment. I think we need to move it forward. Lars: Asking for a fabric upgrade is a tall ask. If it can't be used by apps it won't ever be used. The IETF has done some changes, both in the network and in the endpoints. ECN requires both. We need heavier thinking about the incentives and how this will manifest itself in applications. Koen: In the past we saw specs, but no network interest. Now we have the opposite, network interest with good engagement and plans to deploy it. This means we can do the experiments now, let's move this forward. Bob: The network will not deploy it without an RFC out there. Gorry: How many would review and comment on a last call if we start one before next IETF meeting? 18 hands raised, 2 not raised, 52 participants at time of poll. Jonathan Morton (chat): I think WGLC at least has to wait for l4s-ops to be completed. Mirja Kühlewind (chat): I disagree, let's get things moving. Sebastian Moeller (chat): DualQ does not equitably share between the two classes in a number of relevant cases and requires the protocol to work as expected. Koen Schepper (chat): +1 to starting a WGLC: Only the real experiment can bring more engagement and experience. Greg White (chat): +1 to starting WGLC and to starting the experiment. Ingemar Johansson: The opts draft is not required before a WGLC of the L4S, on the contrary, I would see that the ops draft will in part be a result of the experiments. Carsten Bormann (chat): The purpose of an experimental RFC is to agree what exactly the experiment is. Sebastian Moeller (chat): Making the endpoints responsible for safety and equitable sharing is an odd choice, since the same endpoints will profit from unequal sharing. Andrew McGregor (chat): The ops draft is required... but it shouldn't be last called until after the experiment is done, because it will become the ops document for the eventual standard. Jonathan Morton (chat): There is also a risk that deploying the experiment will "eat" the ECT(1) codepoint and prevent it from being used in a different way later. Gorry Fairhurst (chat): I think Jonathan is correct, the intention is that TSVWG will assign ECT(1) for this, until the experiment is discontinued. Mirja Kühlewind (chat): We discussed the question if RFC 3168 marking is being deployed. If the question is no, L4S deployment is much simpler. If those who have deployed RFC3168 are the first once to update to L4S that fine as well, if the answer is no Colin Perkins (chat): I don't see how that data can be found without trial deployments. (+1 from Jana Iyengar, Ingemar Johansson, David Schinazi, Mirja Kühlewindd, Ram Ranganathann) (for more details see Jabber log). The chairs asked who would review these Specs if the WG were to start a WGLC? 18 would review (+1 via chat), 2 would not (out of 52) All Other Business 8.1 Davide Brunello’s thesis work relevant to L4S (No time this meeting)