TSVWG interim meeting - 8 April 2020 Recording started 7:09 Pacific - Note-taker Jake Holland - Introduced Martin Duke, who is the new responsible AD. - Note-well shown - Instructions on remote interim participation 7:14 WG achievements review 7:17-7:19 objection from Ekr about the WGLC on transport-encryption. there was an intended process clarification from David - Objections raised in WGLC that appear to the chairs to be "in the rough" and will go in the shepherd writeup, and will be worked through during IETF Last Call. Draft status updates Agenda summary until 7:30, unbashed. 7:33 Bob presentation re: ECN fragmentation reassembly. - Magnus: Is it really causing multiple congestion events at TCP level, or is it an assumption that it's marking fragments in a random distribution? - Bob: It's because you have twice the packets so you get twice the congestion events - David deferred to discussion of following draft. - Refer to the prior list discussion advice from David: https://mailarchive.ietf.org/arch/msg/tsvwg/V_l4laD6ECKz3oinwy4UOPmatBM/ 7:44 Michael presentation on 4960-bis - Chair advice & discussion 7:49. David: Please provide a list of important changes somewhere in 4960bis. Michael: We can refer to the RFC and explain key differences. Gorry: I will work with Michael. 7:52 Michael presentation on natsupp. - Chair discussion 7:56. Abort-handling refinement suggestion from David (write up the downside of not receiving an Abort and then we can decide on strongly recommended SHOULD v MUST). Gorry: +1 - Med (7:59): Regarding the NAT function/device terminology: Just pick one term, use it throughout the document, and say equivalent terms at the start. + more detail needed on fragmentation, more important than NAT terminology. - Gorry, David: +1, You need to explain SCTP's dependence on IP fragmentation and the consequences. - Magnus: Are there pmtu requirements? - Michael: Yes, if you use PMTUD, then when the size changes there is a short term fragmentation need for retransmission for any data sent with a larger size. - Gorry: When will this be ready? - Michael: In about 4 weeks 8:05 Greg on NQB - David: 2475 g.11: traffic protection is part of config and management. - Gorry: Please take the diffserv codepoint selection separately, please discuss on-list, maybe we can provisionally allocate once we all agree it will "work". - David: agree, will start that discussion. 8:14 Martin quic-natsupp NAT support for QUIC - 8:19 David: +1 I'd like to see an Informational RFC - Mirja: We should definitely be mentioned in QUIC ops draft in some form. - Gorry: +1 on being the Ops draft. - Colin: NAT implmentors might not read it, but we should document it regardless. also: it is important to note there is other UDP besides QUIC. - Spencer: +1 on a standalone doc, +1 on RFC. The "audience is the opposite of the NAT vendors, it is network providers who can show this document to their NAT vendors", +1 on mention in QUIC OPS draft with reference. - Gorry: The feedback from WG is positive. Next step: talk to the "irresponsible" AS for TSV (since the responsible AD for this working group is the draft author). We will coordinate with QUIC if it goes ahead in either group. 8:25 Jerome on Mapping QCI to Diffserv - David prelude: 3gpp had a negative reaction initially, they now less negative. Value of the draft, intended audience, how it relates to 3gpp standards is the focus. - Jake: consider dynamic. take a look at https://tools.ietf.org/html/draft-knoll-idr-qos-attribute-24 - Spencer: different diffserv mappings moves this more important to move forward. also: how often will we have to revisit this? Like every 2 years? - Jerome: 3gpp on a 10-year cycle. - Spencer: Cool, then if we can get mostly marking the same in different networks, especially across home networks/transit networks/visited networks, that would be useful, and this document would be useful to more than just 3GPP network providers - Subir: wifi might be in the same operator's network as 3gpp link. If it's managed by the same operator, maybe they'll use the same markings? - Jerome: carriers know what they're doing. if it's their own network they'll make a good choice for them. this draft more useful when an enterprise has an SLA with a carrier and would like to align the 3gpp link and the unlicensed link to the same behavior. - subir: is the draft clear on that? jerome: please let me know if not - Michael Tuexen: p14, the table looks terrible. (jerome: yes, something happend, thanks, will fix) - Chair comments David that this doc could decide to start as Informational, but if it becomes useful and adopted the group can decide on BCP later. This may be digging in the right place. - Greg White: This doc allocates space from pool 2 and pool 3 (local use space) is this suggesting IANA assign these? - Jerome: yes. - Greg: That's a significant chunk of the available space. lot of potential uses for those codepoints, nqb a case in point that conflicts with these. - Gorry: We don't normally allocate so many codepoints in an RFC and not an informational RFC. Please check what you think you need from IANA and which Pool. - Subir: 3gpp history includes codepoints from ATIS, this relies on flexibility for operators to self-assign. Allocating codepoints with IANA would be tricky and difficult. This is why 3gpp gives operators the flexibility on qci etc., so they can interoperate with other networks. have to be careful here. - d=David (chair): Does this mean we need to coordinate with another standards body besides 3gpp? - Subir: Yes, Alliance for Telecommunications Industry Solutions (ATIS) https://www.atis.org/ and some others. (Gorry: Are there gsma and other industry groups also?) - Jerome: Carriers are working on normalizing this. This is about the exchange point primarily. Traffic types upon leaving the domain is where we potentially need somethingT - Subir: Yes, this is about use cases as you mentioned. The problem is asking for (many) new IANA codepoints. We need to be careful to get a review from all the organisations. We will sync offline, but in the WG we should be careful. - mMrtin: Are you asking to assigning new DSCPs or just using existing DSCPs and mapping to 3gpp behaviors? - Jerome: In this draft we do both. Where possible we map, but for new functionality we assign new ones. - David: If we conclude a new one would be needed, this is fine, but a document that asks for allocating goes a lot further. Gorry: +1, It was great to hear discussion here. The document now needs a lot more discussion - Spencer: to avoid the 'bring a rock game' ("that's not the right rock, please bring us another rock" repeated infinitely): can we give the authors guidance on what a non-large number of code points to assign would be? - David: This is easier than that: as a non-standards track doc, this draft cannot allocate new DSCPs. This draft is Informational. Actual allocations would be done in standards-track drafts, similar to NQB PHB draft discussed previously. - Gorry (chair): This will require expertise and standardization decisions. The WG will not start this activity yet, but this is digging in a good place. - David: Careful coordination with 3gpp is essential here. 3gpp people are not on this call, so we need to reach out and get input. Please loop in martin please. - Martin: Is the informational draft without biting off standards addressable at this point? - Gorry: No. The chairs would like to see another rev first. The authors got feedback, and people may have thought it less horrible than originally planned, so it might have legs, but we need to see more. No other questions. The WG closed.