Minutes IETF105: tsvwg
minutes-105-tsvwg-02

THURSDAY, July 25, 2019, 1000-1200  Morning Session I, Laurier
Chairs: Gorry Fairhurst; David Balck; Wes Eddy (remote).
(Notetaker: Theresa Enghardt)

1. Agenda

2. Chairs Update:

        RFC's completed/in Queue:
        draft-ietf-tsvwg-le-phb  (RFC) Document Shepherd: David
        draft-ietf-tsvwg-fecframe-ext (RFC-Ed) Document Shepherd: Wes
        draft-ietf-tsvwg-rlc-fec-scheme (RFC-Ed) Document Shepherd: Wes
        draft-ietf-tsvwg-tinymt32 (RFC-Ed) Document Shepherd: Wes

        Drafts beyond WGLC:
        draft-ietf-tsvwg-ecn-encap-guidelines (WGLC) Document Shepherd: David
         draft-ietf-tsvwg-rfc6040update-shim (WGLC) Document Shepherd: David
(new text on fragmentation, review needed)

Gorry: The text on tunnel remarking has changed in the latest version.
Bob Briscoe: This text was written after WGLC responding to a WGLC comment.
Gorry: It is unusual to have so much new text, we need to make sure we have
review of this text by the WG. Markku Kojo: This is not the RFC3168 mechanism,
I've sent comments to the list (about how to deal with fragment marking). Bob
Briscoe: I plan to revise the text after the meeting. Chairs: Please make a new
ID and we'll evaluate whether this is ready or needs another WGLC.

(Slide 10: Related Drafts (2))
The overload protection ID is probably headed for independent submission to the
ISE: Low latency DOCSIS Bob: We haven't spoken about this, but probably yes.
This documents what is done in DOCSIS, rather than defining a new iETF
mechanism. Gorry: Future work on this topic would likely fall within the WG
remit. WG, please review this ID for technical clarity.

        Chairs: Milestone updates

        Chairs: Announcements and Heads-Up

2.1 Heads-Up Socks Proxy 6
(draft-olteanu-intarea-socks-6-00)

Chairs: Has anyone read a recent version? (1 for previous version)
Gorry: Please read and comment on list. Please consider this as a potential
TSVWG work item.

3. Transport Protocols and Mechanisms

Transport Encryption

3.1        Colin Perkins: Impact of Transport Header Encryption (WGLC)
        draft-ietf-tsvwg-transport-encrypt

Tom Herbert: Is the latest version of draft is more positive to extension
headers? I still think it's a little negative. We need to get better
measurements of HBH options in the Internet, and find more recent data. Gorry:
Please check current version. Tom: Deploying IPv6 HBH options is a known issue
we're trying to resolve. There's lots of efforts to resolve it. At least
suggest this approach could be used. Wording will be interesting. I'm not sure
I've ever heard of intentional ossification. Colin: Protocol may make an
explicit statement to declare features stable for all time, so you can assume
they won't change. An example is QUIC invariants. Joel (Jaeggly?): When we bake
something into an RFC we're kind of doing that. We are literally aiming for
things to not change. Colin: There is a difference between this and a
commitment to never change these bits. Joel: If you want to change the
three-way handshake in TCP, good luck. Standardized doesn't mean it's not gonna
change. Colin: Here, harm comes from a path preventing a change the
specification in ways we want it to change. Tom: We now have two major
transport protocols. One of the bits of QUIC was public, a middlebox vendor
ossified it. Classical ossification we want to avoid. QUIC and TCP need equal
consideration now. Colin: RTP is very widely deployed too, and did fix visible
headers. Matt Matthis: In the past, there were drafts saying to enforce "must
be 0" in headers and middleboxes checked this. That's ugly. Occasionally this
creates attack vectors. Alissa Cooper: What about  review from security area?
Gorry: We discussed the SEC review last meeting. The security review was a long
one, and really good. We went through comments and responded to each one, then
updated the document. We added in text to address nearly all comments, and
responded on mailing list why we didn't think some additional text would be
helpful. I don't know if reviewer posted an update on whether they think it's
fully addressed. Colin: I ad long discussion with Chris Wood - who was the
reviewer. There was also an earlier review by Stephen Farrell. Alissa: Good to
know. The document is not entirely unrelated to a previous doc, there is a
chance that some language hits a series of people. Colin: We have presented it
in OPSEC several times. Alissa: Some concerns could be dealt with while the
document is still in the WG. That would make things easier. Get the feedback
earlier. David: We plan to ask other areas during WGLC. Gorry: We welcome
feedback. However, it is important that this ID documents, raises questions,
but does not propose new solutions.

Chairs: The next revision will go to WGLC, expected in August - if so, we will
make this longer than the usual 2 weeks - because it will be in August. We will
cross-announce to the OPS and SEC area.

3.2         Igor Lubashev : Loss Signaling for Encrypted Protocols (Individual)
        draft-ferrieuxhamchaoui-tsvwg-lossbits

Aaron Falk: There is great interest to Quantum Internet Research Group that you
use Q-Bits. Tom: What else is there, what other information? I'm worried if you
give a mouse a cheese... Protocol-agnostic is better than protocol-specific
mechanisms. How do we unify? Gorry: The current presentation is just one
presentation in this space. There are other topics that are related, and they
will all request bits to convey info. Martin Duke: If it's in QUIC header, of
course it's authenticated. Not anyone can mess with those bits. Igor: We do
mess with IP header bits, it's not going to be any different from what people
can do right now. In the QUIC header it will be authenticated, there's
advantages and disadvantages to any  proposal. That's why we don't dive into
details right now. We would like people to agree that this is a problem and we
need to solve it. Martin: The threat model a serious problem when using
measurement data that is authenticated? Igor: If a sender is playing fair and
keeping a separate counter, I don't think it's an important threat model. Mauro
Cociglio: I suggest to add a reference to RFC 8321 about ways to measure packet
loss, use for case two different measurement points to understand packet loss
Igor: We will definitely do more. This just uses one probe, one direction of
traffic. Once you identify which direction a loss is, you could have another
probe. ?: Can you compare with congestion exposure? There's some similarity.

Chairs: Please continue to discuss this ID on the list.

SCTP Drafts

3.3        Michael Tuexen: bis update two SCTP Spec.
        draft-ietf-tsvwg-rfc4960-bis

Gorry: Have you looked at the ID with suggestions for a next generation SCTP
(Individual draft)? Do you see anything taht needs to be in the bis document?
Michael: We integrated almost all the errata in the base spec. Except for one
document describing the I-Bit. The other suggested additional work is on
changing concepts. I don't think anything applies here except the I-Bit. Gorry:
If the WG thinks there are any other additions to this document, please come to
the mic. This document is meant to be a stable specification for this protocol,
and we don't want any last-minute proposals. When is next revision? Michael:
Maybe tomorrow.

        Michael Tuexen: NAT for SCTP
        draft-ietf-tsvwg-natsupp

3.4        Maksim Proshin: Retransmit bit for SCTP DATA, I-DATA and SACK
(Individual)
        draft-proshin-tsvwg-sctp-rtx-bit

David: What is your intention for this draft?
Maksim: I asked for adoption and I will update.
David: See you in Singapore!
Michael T: Do we need negotiation? What if a receiver does not understand?
Maksim: You can mistakenly think that your first original send... yes, needs
negotiation. Gorry: This looks like good plan, but what is the complexity?

Chairs: Please continue to discuss this ID on the list.

Transport Working Group Drafts

3.5        Gorry Fairhurst: Datagram PLPMTUD
        draft-ietf-tsvwg-datagram-plpmtud

Gorry: The draft contains all the framework, and is stable. There are some
topcis requiring research, and measurements - but these are not the purpose of
the current draft. We think this ID is nearly ready to publish.

Chairs: We expect a WGLC before next IETF. Removal of UDP the options text was
an executive decision by the chairs in the hope to get this published before
the UDP Options work is complete.

Tom Herbert: Is there implementation?
Gorry: There have been 4 implementations we know about. There is FreeBSD work
in the git, this won't be upstreamed until spec is finished. There was another
project in git. Another in the QUIC at hackathon into mozquic. Tom: Good to add
a reference to it. Gorry: We will have this in shepherd writeup. Not sure if it
is useful to add to the draft? Michael: We have implemetations on demo
applications. We did an early implementation , but this has changed as the WG
document finished. We hope to update the latest algorithm in our SCTP
implementation.

3.6        Joe Touch (proxy/remote): UDP Options (20 mins)
        draft-ietf-tsvwg-udp-options
(Presented by Gorry)

David: A crucial text change is if the UDP checksum is not zero, you have to
use the OCS. There may be a corner cases with tunnels, this needs to be worked
out on the list.

David: There has been proposal for a must-support flag in the option header,
which indicates that no further options will be processed if this option cannot
be parsed. Any objection? Tom: I expected discussion here? David: The chairs
are looking for a sense of the room on the proposal. Matt: Does this allow
rewriting packets? To drop headers without dropping packet? David: No, this is
receiver behavior for an option that is not supported. The most you can do is
to toss the option and later options. Mike Herd: Yes. Magnus Westerlund: I
think that is the right way.

Tom: I think it is more than ceasing option processing. Based on IPv6 HBH
options. This bit in an IPv6 option type tells the receiver to skip an option
not recognized or to drop the packet. Drop the packet if not recognized,
because the rest of packet may be incorrect. This means you can't have options
that modify the data. Two use cases for UDP options: A Trailer with a UDP
payload, I agree. In node 2 (?) there's no legacy receiver. Payload in surplus
we can do what we want with it. Gorry: Are you saying if anything is critical,
a receiver should drop options? Tom: Drop the packet. That is the IPv6 way.
David: We are retrofitting here to UDP, not disturbing the existing UDP
payload. Tom: We already cannot deliver data that has not been properly
processed. We cannot deliver fragments to applications. We need to be careful.
David: When we use fragmentation, all of the fragment data is sitting in the
UDP options area. Tom: There may be other cases where we cannot deliver that
data. Encryption, compression? Gorry: Agree these could be done as options, but
I do not yet see a new point. David: If there is UDP payload and a problem in
options processing, then you can drop options, but can't drop the UDP payload.
Tom: We may need this for extensibility. You want to make sure we can have
version 2 and we can have this option in case. Mike Heard: The problem is that
some options affect data handling, so data must share fate. What Tom said and
we see it in the encryption case as well. Gorry: Let us make sure this level of
agreement is actually on the list and that Joe is on the same page.

David: Going forward we maybe could divide the option space for critical
options. We'll figure this out on the list.

Gorry: Do we need the LITE option independent of the FRAG option? If we remove
that, it'll be simpler. Magnus suggested on list that UDP-Lite equivalence is
not needed and I agree this raises more issues than it solves and is unlikely
to be ever used.

Gorry:
David: If you're doing DNS fragmentation because DNSSEC, you got individual
checksum, do you also need reassembly checksum. Shove it in the application? If
application is doing its own, does not remove need for OCS, make sure packet
goes through the path. Tom: Agree David: Focus on: Does this do something
useful for DNS? Mike Heard: No LITE option trailer, it does bad things to
legacy receivers. David: One more voice for not keeping lite. Tom: Log all
stateful or stateless options. I prefer the IPv6 method. If I have both of
these, I can use the same implementation as for HBH options. Mike: Already ACS
option for reassembly checksum.

(CRC)
Gorry: We should not be using a CRC-16 for this length of data, SCTP and other
specs use a CRC32c. David: iSCSI also uses a CRC32c, it's easy to implement
with modern CPUs. Mike: CRC-16 was agreed on the list some time ago, but I
agree that this decision should be revisited.

Chairs: We expect Joe to collect the inputs and produces a new revison of the
ID. It will then become clearer what issues remain.

4. New Work

4.1        Aseem Choudhary: RTG area (Diffserv and Yang)
        draft-asechoud-rtgwg-qos-model
        draft-asechoud-rtgwg-qos-oper-model

David: Nit: You cannot use ranges with DSCPs, only a list of codepoints.
Gorry: Any other comments? Can anyone help? Please ask on list as well. Are you
looking for adoption in routing area? Aseem: Yes.

4.2        Jerome Henry: QCI and Diffserv API (10 mins) (TBC)
        draft-henry-tsvwg-diffserv-to-qci

Jerome: We are looking forward to feedback from the 3GPP liaison. This is meant
to be informative text, the first step is to express the intentions of this
text. We do not wish to impose anything. e.g., we provide the intention of
mappings if people build a multipath system. Translate these one to the other.
Martin Dolly (AT&T, 3GPP): The table referenced on QCI is an informative table.
Each carrier uses DSCPs differently, QCI can be as well between different
carriers. Moving forward to 5G, the table is ever changing. Moving target and
informative. Any kind of MUST language referring to an informative table is
probably ill-advised. In addition, this is most useful for private network
deployments, but not for carriers who already know how to provision their
networks. David: Let's get the new text. This is potentially useful for private
networks as starting point.

Chairs: We expect a new revision of the ID for people to discuss.

4.3        Greg White: Identifying and Handling Non-Queue Building Flows  (15
mins)
        draft-white-tsvwg-nqb

David: Please don't put a specific non-IANA-assigned DSCP into running code!
Gorry: ... yet.
Martin Dolly: Thank you for your help with this.
Subir Das: Thanks for this draft. Softening that language helps. For the WiFi
sections you have SHOULD, but for LTE you have MUST. Why? Greg: The reason is
just editorial, depending on which of the co-authors wrote that. I don't think
there will be a concern. Gorry: Obviously the WG would have to decide on the
recommendations. Chris Lemmons: You have SHOULD for protection against
mis-marked flows. Application that does not implement that are in a sorry
state. If application can classify, why do we need DSCP? Greg: The reason this
is a SHOULD, is that some queue disciplines do not need to implement this, like
per-flow queue systems. Gorry: I suggest this needs more text. Subir: Security
considerations is a good thing. Maybe this needs more elaboration on who is
responsible for marking this.

Chairs: Who has read? (12-15)

Chairs: Can we have a hum if this topic is worth pursuing in the WG?
YES: Strong hum
NO: Silence

Adoption? Hum:
YES:Sstrong hum
In doubt: Silence

Magnus: There seems a very clear consensus that we can adopt this.
Chairs: We agree. The Chairs will confirm this on the list.

FRIDAY, July 26, 2019,  1220-1350  Afternoon Session I - Place du Canada

(Notetaker: Michael Scharf)

5. Transport and Network - Chairs

        Wes/Gorry: Review of WG discussions preparing for WGLC of L4S drafts

Chairs: The first item on the agenda will be a summary of the IPR discussion
that has taken place on the list from the chairs' perspective. Disclaimer: Full
version: The chairs are not lawyers.  This is not legal advice.  If you want
legal advice, you need to talk to a lawyer.

(No comments allowing the summarised IPR)

5.1         Bob Briscoe: L4S ECN drafts
        draft-ietf-tsvwg-ecn-l4s-id
        draft-ietf-tsvwg-l4s-arch
        draft-ietf-tsvwg-aqm-dualq-coupled

Slide "Implementation status"

Andrew McGregor: Are you aware of anybody who is working on putting L4S support
into the Linux WiFi stack? Bob: I am not aware of anybody doing that. Do you
volunteer? Andrew: Unfortunately I may have no time for that.

Slide "Open issue #1: RFC3168 ECN in a FIFO"

Jake Holland: Akamai has observed ECE codepoints in the wild in the Internet.
Some production traffic has ECN enabled. Some servers indeed see some ECE
marks. Rod: Help from operators to get data would be very valuable.

Gorry (chair): Would this need a change to the 3 specs?
Bob: Not to the spec, but I can update the text.
Gorry: Sounds reasonable.

Chairs present slide deck with potential discussion topics seen on the list.

Jake Holland: I would like to add one item to the list: Admission control for
untrusted markings in a classifier. Gorry: This is classified as useful
research in RFC7567. What do you suggest? Work in the WG? Jake: That is an
interesting question. I don't have an opinion right now.

Christian Huitema: Evaluation of the L4S experiment. All slides compare L4S to
CUBIC, which is not designed for low latency. I would like to see a comparison
to a delay based CC, in particular BBRv2. Bob: We are waiting for BBRv2.
Jonathan Morton: I have 4 topics: f) IETF approval is required to use ECN. g)
Incremental deployment requires compatibility, which has not been demonstrated
so far. a) Effective congestion control is required. FQ_Codel is the most
deployed AQM. With the current Codel, the time to reach the correct marked rate
would be 4 seconds (?). 4 seconds for a link with 10ms is not effective. b)
Fair queueing is fairly robust. My concern is when there are two consecutive
bottlenecks. In our experiments we have found issues. Chairs: This sounds like
an issue in FQCodel.

Peter Heist: I highlight 2 topics:
e). A strong concern against using ECT(1) as classifier. DSCP relies on domain
security at domain borders. With ECT(1) there would be no borders. h)
Implementation status. There are issues in the repo. TCP Prague is
over-reacting in experiments. There will be further interop testing.

David Black (from floor): Regarding open issue #2. The whole point of the L4S
experiment is an experiment for the Internet as a whole: this was much
discussed before we adopted this work item. The interaction between queue can
occur anywhere in the Internet.  But resequencing is different. For instance,
for wireless links there can be asymmetry. But, this does not happen inside
data centers. The underlying cause for resequencing delays does not exist
there. The problem mostly occurs in specific access networks. It has to be
solved there. It is not appropriate to mandate that all Internet end nodes be
modified in order to take advantage of L4S.

Gorry: We need clarity on what the intention is. Is this specifying recovery in
terms of time - which could then lead to relaxation of sequencing requirements
*or* is this specifying a relaxation now? The latter would need cross-area
review before moving forward. Bob: It is the former. We are saying that a link
has the capability of not doing resequencing packets with the identifier.
David: This is proposed as Internet-wide experiment. I still believe that this
has a major scope problem. Bob: The relaxation is only for ECT(1). There is an
opportunity to use a time-based loss detection. It seems like a good
opportunity. David: I see the opportunity for a separate experiment. Gorry: As
chair, I concur with David that describing other features apart from the core
requirements for the ECN experiment really needs to be put in a separate
experiment. If we do that, we will have to go to Int Area and RAI. Bob: The
document only says what the endpoint must do. It does not day anything about
the node. Gorry: Does the annex needs to be there? Bob: No, the annex is not
needed. Gorry: With QUIC and RACK being deployed, tolerance to reordering may
improve anyway. David (from floor): You are running two experiments. Is the
annex is normative? What if we pulled the annex into a separate, informative
document without any normative reference from the L4S spec. Bob: The normative
specification in the main part could be a SHOULD.

Chgair: As chair, I would recommend removing the paragraphs from this document
that lead-on from the experiment and those that pass comment on DSCP
deployability, we think the current text requires additional cross-area review.

Jake: This list is a list of technical considerations and I agree. In addition,
I have raised on the list editorial considerations. There are significant
editorial issues that I think must be addressed before moving the document
forward. Gorry: What do you mean? Is this about the section order? Jake: This
is about word choice, and ensuring it only makes technical claims. Gorry: This
is excellent feedback. Please do send notes to the list. Jake: I sent a review
of one section to the list. I am waiting for feedback. If I continue, it will
be quite a bit of feedback.  wanted to raise the issue about the wording.
Please reduce the hype. Bob: I understand this comment. I have started, but not
finished the reply - I think I know what to do and will revise.

Chairs: Time for some hums...

How many have read -architecture ID?
(15-20) (+1 on jabber)

How many have read -id ID?
(15) (+1 on jabber)

How many have read -dual-queue ID?
(15-20) (+1 on jabber)

Wes: Does anyone want to bring up IPR?
Rod: The ersons who want to speak to IPR are not present.
Jonathan: Dave That wants to speak to this later, he could not join.
Chairs: Please read the IPR summary and decide on your own position.

Chairs: Are these documents ready for evaluation in a WGLC? Please hum.
("yes": Weak hum, "no": Weak hum) (Jabber: +1 "no" from Dave)

Magnus (AD): Some people think the current text is not ready. The text needs
revised. People should have some few weeks to send technical comments to the
list on what needs to be addressed. If you have technical concerns why it is
not ready, please tell us.

Chairs: This is a good idea, we plan to revisit this next month when a revised
ID is available.

5.2         Bob Briscoe: Transport for L4S Data

6.New Work (if time permits)

6.1         Jonathan Morton: Some Congestion Experienced
        draft-heist-tsvwg-sce-one-and-two-flow-tests
        draft-morton-tsvwg-sce
        Related drafts:
        draft-grimes-tcpm-tcpsc

Slide #7

Mirja Kuehlewind: For the CUBIC-only flow, what AQM is used at the bottleneck?
Jonathan: Cake, i.e. FQ_Codel, with standard parameters

Gorry (as individual): What is the pink plot? Is this with fair queueing?
Jonathan: The two flows get separate queues.

Slide #8

Gorry (as individual): Is this one FQ?
Jonathan: This is single queue and there is convergence.

Discussion:
Gorry (from floor): Were the changes you mentioned upstreamed?
No.
Gorry (from floor): Please do post links to the patches.

6.2         Markus Ahmed: DCCP Extensions for Multipath Operation
        draft-amend-tsvwg-dccp-udp-header-conversion
        draft-amend-tsvwg-multipath-dccp
        draft-amend-tsvwg-multipath-framework-mpdccp

The authors provided a short presentation after the meeting (see slides). There
was no time to discuss this ID at the meeting, but they suggested the topic
could be prioritised for the next meeting. Please read the drafts and do
discuss this topic on the list.

6.3        Other items - please contact the Chairs

None.