Minutes IETF104: tsvwg
Transport Area Working Group
||Minutes IETF104: tsvwg
TSVWG at IETF 104 Prague
Monday, 25th March 2019, Afternoon Session II 1610-1810
Room Name: Congress Hall 1
WG Chairs: Gorry Fairhurst, David Black, Wes Eddy (remote)
Note-takers: Brian Tramell, Yingzhen.
2. Chairs Update:
draft-ietf-tsvwg-rfc4960-errata (AD) Document Shepherd: Gorry
Drafts beyond WGLC:
draft-ietf-tsvwg-le-phb (IESG) Document Shepherd: David
draft-ietf-tsvwg-fecframe-ext (IESG) Document Shepherd: Wes
draft-ietf-tsvwg-rlc-fec-scheme (IESG) Document Shepherd: Wes
Drafts awaiting WGLC:
draft-ietf-tsvwg-ecn-encap-guidelines (Need reviewers + another WGLC)
draft-ietf-tsvwg-rfc6040update-shim (Need reviewers + another WGLC)
2.1 IANA Registries
2.2 Milestone updates
ECN encapsulation drafts are being prepared for WGLC before next IETF.
L4S drafts are being prepared for cross-area IETF.
PMTUD framework is targeting WGLC after next IETF.
2.3 Announcements and Heads-Up
MISSREF*R(1G) document in C238 has been overtaken by LE-PHB
2.4 Implementation (Feedback from Hackathon on experiments)
Bob Briscoe: On TCP-Prague: 80-10 people have been patching Linux for L4S
and QUIC-Prague. We have built a virtual test environment and been
looking at offload engines for Linux.
Tom Jones: Seven people have been working on basic support for IPv6 HBH
headers that follows on things presented last IETF.
There is still work needed to see how signals can be integrated into
Jake Holland: Has any work been done on Accurate ECN and RACK?
Bob: This was mainly the place where GSO was worked upon. This code
is also useful when you have not been using L4S.
2.5 Other Drafts Related to TSVWG
draft-eastlake-sfc-nsh-ecn-support - For info (Please discuss on SFC list
draft-li-tsvwg-loops-problem-opportunities - For info (Discuss on TSVWG list)
There is a side-meeting on Wednesday regarding loops.
There are also various drafts in INTAREA, including:
Tunnel encapsulation, GUE, and draft-olteanu-intarea-socks-
2.6 Vincent Roca: RLC Fecframe
This draft was introduced to solve an copyright and Licence. Adoption is
requested by the Chairs at this meeting. The code was also updated to
clarify ambiguities in representation of negative numbers.
Spencer: IESG evaluation also looked at portability of the code, and
this addressed the need to work in multiple environments.
3. Transport and Network
3.1 Gorry Fairhurst (editor): Impact of Transport Header Confidentiality
The document has completed SecDir review, and updated were described.
Authors plan to update the summary.
Aaron Falk: I have not read the draft. Is this document making recommendations?
I am concerned that this draft may be published and it may never be acted upon.
Tom Herbert: This document describes the impact, but people may not act on it.
I think encryption is coming. What is the solution? We could use extension headers
to restore visibility of encrypted info.
Gorry: I think we could. This provides understanding of why people are currently
using transport header information, and potential impact and pathways for evolution.
This ID does not solve problems.
Tom Herbert: I am not convinced protocol development relies on this, google has
deployed methods. It is rare that endpoint developers look at the network details
when deploying new features.
Spencer Dawkins (as AD who is stepping down): This draft is valuable as a description
by transport experts of what is being done. This sort of background is a really
helpful basis for pointing to when we start to do all the new things we have talked
Gorry (ass editor) Can we start a WGLC please?
David; Yes. The Chairs need to coordinate on the order of conducting the WGLCs in the
period up to the next (Montreal) IETF meeting.
3.2 Bob Briscoe: Low Latency, Low Loss Scalable Throughput (L4S) ECN drafts
The ID now has a section to indicate that Fair Queueing AQMs can support L4S.
We have dual queue code for Linux, Curvy RED implementation is not yet public.
TCP Prague is Linux only. Running TCP Prague code should be configurable to
meet the RACK-like reordering requirement. Bob would be interested in
understanding if existing CE-marking is from FQ systems (where there is
safety from other flows).
There have been a number of supportive and non-supportive reviews.
Michael Scharf: I am also one of the non-supportive people.
Gorry: It could be helpful to add a separate section in the document
how an FQ system could be updated in the next version.
Bob: We plan this.
Chairs: How many people had read the L4S Architecture draft?
— About 15
Chairs: How many have read the Dual Queue draft?
— Slightly less.
Chairs: The Chairs would like to hear whether Dual Queue AQM can be
implemented without the declared IPR?
Bob: There are three IPR declarations.
Chairs: Please come to the Mic or discuss this on the working group list.
Bob: As a personal note there is a GPLv2 licence for the Linux version of
Bob: You could use another AQM such as Curvy-Red. This has beed used
in the high-speed switch.
Rodney Grimes: Are all of the pieces to implement L4S documented in IETF?
Bob: The only thing that's missing is queue protection (which is in
pseudo-code in the DOCSIS spec). We will be sending a draft.
There is also coming ns3 code.
David: How close is TCP-Prague? Or QUIC-Prague? to solving the RACK requirement
Bob: If you use pacing, this may be very close.
Gorry: Will the next revision of ID and Arch be ready to send it to the INT Area
review team for early review?
4. New Work
4.1 Jonathan Morton: Some Congestion Experienced (SCE)
This proposes an ECN field transition between ECT(0) and ECT(1)
known in this proposal as SCE. The reverse transition needs to
the prevented. We plan to look at the entire congestion control
feedback loop, including at least a couple of sender reaction
mechanisms to make sure that they do what is wanted/expected
before and/or in parallel with experiments.
Brian Trammel: How long do you think this may take?
Jonathan: We are making reasonably rapid progress in a few months.
Gorry: Do you plan to update the draft, and when can we expect the next revision?
Jonathan: We plan to do that in a few months.
Jake: I believe the SCE draft talks about rend feedback. How do you see
the different feedback methods working out?
Jonathan: I plan one document on SCE, and others describing its applications
to AQM and transports. The receiver-side solution may not be the
best solution. We also have ideas of using the former NS-bit or
accurate ECN or some other options.
Bob Briscoe: I think CE markings in this scheme are for backwards for classic
compatibility. An end system that reacts to SCE is very unlikely
to see CE-marks. Using a 3-level signal could happen in slow start, but
you do not want the CE signal in this case. What is the behavior of
tunnels of SCE with tunnels? Deployed tunnels that could revert ECT(1) from
within tunnel to ECT(0) before RFC 6040 was introduced (e.g. L2TP).
Jonathan: In that case, the SCE information could be erased. Classic ECN
would then react, which would be safe to survive.
Chairs: Please discuss on the list.
4.2 Greg White (remote): Identifying and Handling Non-Queue Building Flows
in a Bottleneck Link
The goal is to identify and enable L4S for sparse traffic. This adds a
Non-Queue-Building traffic class that is expected to be below the capacity.
David: The idea of protecting queues appears to be a “SHOULD support”.
We will likely have to be "MUST support" for redirection
of queue building flows to enable operators to thwart theft-of-service attempts.
Greg: It could be promoted to a “MUST”.
Bob: This is a policy decision.
David: Must implement. Operators can then choose to use or not.
Chris: Where did loss come from in the (related) LoLa draft?
Gorry: We should look at each L2 technology in turn to see how this would work.
Gorry: Why do you propose a specific DSCP?
Greg: I think this classifies in WiFi to map to an appropriate mapping.
David: Please see RFC 8325 and please update the draft accordingly, which may need a
Greg: I am aware of this.
Jonathan: NQB is not supposed to be a priority, but this seems to give it priority.
Greg: We are looking to map to an appropriate category in WiFi, and this is
how it may fit into existing deployments.
Michael: This is the prefix as EF. I think we should have that discussion later.
David: We should look at what RFC 8325 says in respect to these mappings.
Paul: Do you have a good reference for other methods to identify elephants.
Greg: If you know more, we would like to consider this.
Andrew McGregor: DNS over TCP could use this, and should be looked at.
Chairs: How many people have read one of the NQB draft?
— half a dozen.
Chairs: Please hum in favour of doing work on this topic?
— a few.
Chairs: Please hum if you are against doing work on this topic?
- a few. The hum showing interest seems slightly stronger.
Chairs: Please continue to work on this topic and discuss on the list.
4.3 Chair’s announcement
The WG is requested to adopt Vincent's tinymt32 draft to solve the
problems that arose at the IESG, unless there is objection. Please send
comments, if any, on the list about this draft.
4.4 Markus Amend: Multipath DCCP
Spencer (as an individual): Please think about whether multi-path IP or
whether multi-path UDP is needed. This is a hard problem, it needs to
be solved once if at all possible. I think this may be a good place
to dig. We are also looking at adding multi-path to QUIC charter,
and held off because it is hard, a general solution would be very useful.
Markus: The needs are different to the way MP-QUIC has currently been
discussed. Propose to change the header to promote better transparency.
Alan Ford: You said reordering is an issue for an unreliable transport?
Markus: Excessive reordering is an issue.
Tom Herbert: When you do implementation, please look at MPTCP and how
they did this.
Spencer: See TSV-Area in IETF-102.
David: When you figure this out, please look at what was done in DCCP WG, and
also request a UDP port if needed.
Chairs: Please discuss this ID on the WG list to progress this topic.
Tuesday, 26th March 2019, Morning Session II 1120-1220
Room Name: Congress Hall 3
5. Transport Protocols and Mechanisms
5.1 SCTP WG Drafts
5.1.1 Michael Tuexen: RFC4960.bis Update
Completed nroff to XML format conversion of RFC5960 source text (rev 00).
Revision 01 reformatted the document. The editors are now applying the
changes from the WG Errata RFC as revision 02.
Revision 03 will start to address the language and clarifications needed,
this will be a document for discussion.
Gorry: To be clear after 03, the WG could still potentially discuss new
topics if there any important issues emerge.
Mirja: Will this obsolete the Errata?
Michael: No, that was informational. RFC4960 would be replaced.
Chairs: The WG could choose to obsolete the RFC4960.bis or not later.
We’d also like to ask if the WG would like to progress this along
the standards track - that is something to consider nearer publication.
5.1.2 Michael Tuexen: SCTP NAT
Maksim: I was concerned about requiring all associations to be tracked.
David: I think the suggestion is to track less state?
Maksim: See detailed comments to reduce the hash table.
Michael: We will discuss this topic and will revise for the next IETF.
5.2 Gorry Fairhurst (Editor): Datagram PLPMTUD
The draft had been edited, and the state diagram simplified. This is now
easier to read. Authors are trying to get more experience and understand
implications of loss, reordering and other path issues.
Martin Duke: Are there implementations?
Tom: There are implementations of the framework, there are 5 or 6
implementations over the lifetime of the draft.
Martin: What was the platform?
Praveen: When QUIC references this will QUIC say this is the method to
Gorry: QUIC allows PMTUD or PLPMTUD. The first QUIC spec is aligned to this.
Christian: QUIC has authenticated feedback.
Gorry: Yes, QUIC does not change the algorithm, and is described in the ID.
Christian: It would be nice to know how to do the search algorithm, and it
would be great to have more data. There are cost/benefits depending on
how much data is to be sent by a QUIC connection. This depends on
knowing more about how the Internet works.
Gorry: This is the main reason the current draft does not define a search
algorithm, it needs some data and some measurements.
Chair: The TSVWG chairs will talk to QUIC chairs about the WGLC milestone
for this draft to avoid causing problems.
5.3 Gorry Fairhurst (Proxy for Joe Touch): UDP Options
David: What is the time frame - will this be active after the next IETF?
Gorry (as WG Chair): This draft is a normative dependency for DPLPMTUD
as written. Is there a way we can ensure the does not cause delay?
I think we can change the document to eliminate this dependency
and allow the UDP Options draft to mature in its own time.
David: The TSVWG chairs will talk to QUIC chairs about timing.
Tom Herbert: I am concerned about distinguishing UDP options use of
the surplus area from other non-standard uses of that area.
Gorry (as presenter): Would requiring the checksum also protect this?
Tom Herbert: Yes, but there is another issue with zero checksum. We really
need a checksum, and would prefer a fixed header that contains it
(current draft has checksum in a variable location). The checksum
is needed for various reasons/
Tom: The idea of option negotiation is unclear in the draft, and needed
for options that are not stateless. How do you deal with unknown
options - startling TCP-style negotiated options and stateless
mechanisms as in IUPv6.
Gorry (as chair): I agree that clarity is important, please discuss
on the list with Joe - the text needs to be clearer.
Christian: UDP options should not be used with encrypted transports.
Gorry: Note that the application is in charge.
Chairs: There is a need to be clear on applicability statement.
Gorry: I don’t know why a QUIC application would choose to do this?
Christian: I assume that a UDP application using network path discovery
will use packets of that size and set DF - you can’t use this.
Gorry: Multiple levels of doing PMTU discovery is never good.
Mirja Kuehlewind: This document is an extension to UDP and the use with
QUIC is not something to discuss here.
The QUIC WG gets to decide whether or not to use UDP options, that
is a topic to be discussed in that WG if needed.
Chairs: Please look at this draft and discuss on the list and with Joe.
6. New Work (if time permits)
Individual Drafts for consideration by WG
6.1 Eric Kinnear: HTTP/2 as a Transport, in Transport Area
This ID has been discussed in the httpbis WG. This is being brought to
TSVWG for consideration of Transport concerns. It looks at a generic
transport for bytes that traverse the Internet. It can also be a
fallback when HTTP3/QUIC does not work on a path. How generic should
David Black (as individual): Please think about MTU - this is
particularly when someone inevitably gateways this into UDP/IP.
See the INTArea tunnels draft for how to think about this.
Spencer (AD): Much more interesting protocol stacks are likely...
You need to think about the worst that is possible in all of our
Eric: We will add text.
Tommy: Where should this get worked on?
Chairs: Transport issues need to be worked here, please continue to
come back and ask questions.
Chairs: We think would finally prefer a single draft, but could use a
short draft to discuss transport here, if that helps to make
progress and get things moving. There are also HTTP and INTArea
issues - this is going to fit between all of these. You are welcome
to bring transport issues here, please come and talk about these.
Spencer (AD): This is an important cross-area activity, we will help.
6.2 Maksim Proshin: SCTP RTX bit
The authors currently have an implementation and plan to ask for
WG adoption of a later revision.
There was no time for discussion in the meeting.
Gorry: It would be good to see performance results, analysis of
the costs and benefits before a WG adoption call.
Chairs: Please read & comment on list if interested in this topic.