Minutes IETF104: tsvwg

Meeting Minutes Transport Area Working Group (tsvwg) WG
Title Minutes IETF104: tsvwg
State Active
Other versions plain text
Last updated 2019-04-02

Meeting Minutes

   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.

Session I

1. Agenda

2. Chairs Update: 
   RFC's completed:
   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
    No updates.

2.2 Milestone updates
    No changes.
    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 
    the code.
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.
David: Do
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
    normative reference.  
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 
    implement this.
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 
this be?

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 
    collective imaginations.
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.