Minutes interim-2020-tsvwg-02: Wed 10:00
minutes-interim-2020-tsvwg-02-202004081000-00

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.