Minutes IETF104: tcpm
minutes-104-tcpm-02

TCPM meeting, IETF 104, Prague
Monday, March 25, 2019, 13:50-15:50 (Afternoon session I)

Chairs: Yoshifumi Nishida (excused), Michael Scharf, Michael Tuexen
Notetaker: Colin Bookham

Note-well/Agenda bashing

-       RFC 8511 (draft-ietf-tcpm/alternativebackoff-ecn) is the only recent
RFC.

WG documents

-       3 covered by presentations during session.
-       draft-ietf-tcpm-rto-consider-08 recent updates and progress on mailing
list. Chairs waiting for reviews before moving to LC. -      
draft-ietf-tcpm-rack-04 has expired (to be discussed). -      
draft-ietf-tcpm-tcp-edo-10 expired. -       draft-ietf-tcpm-rfc793bis-12 has
been recently updated and is in pretty good shape. Chairs discussing what to do
to move this document forward. -       draft-touch-tcpm-2140bis-06 WG
acceptance call finished. Understanding of chairs is that there is consensus to
adopt this document.

Draft-ietf-lwig-tcp-constrained-node-networks-05
-       Presented at IETF 103 in LWIG and TCPM sessions
-       Work progressing on document to incorporate comments.
-       Feedback in general is pretty good, and authors believe the document is
ready for LC.

0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-06
Olivier Bonaventure

-       Converter protocol is an application-level protocol listening on a
well-known TCP port. -       Commands/responses are sent inside the SYN/SYN-ACK
packets and are encoded as TLVs. -       Provides 0-RTT to minimize connection
establishment delays. -       Converter advertises to clients the TCP options
that it supports. Requires no encapsulation (uses plain transport mode). Main
use-case is Multipath TCP. -       Main changes from IETF 103. -       Removed
Error TLV from RSTs. -       Simplified the design by removing TFO. Cookies are
now embedded in the converter protocol. -       Overview of Converter-Assisted
MPTCP (MP_CAPABLE) session establishment (both when server supports MPTCP and
does not support MPTCP). -       Work on this document has been adoption from
Broadband Forum for WT-378 and 3GPP for the ATSS service in 5G networks (TS
23.501).

Praveen: Curious why TFO is not used.
Olivier: Requirement is for cookie. Authors believe it is easier to put it in
the SYN. Praveen: Using TFO API is probably cleaner. Mohamed: Previous versions
used separate TFO, but feedback from other implementations prefer cookie in
TLV. Olivier: Cookie in SYN is yet to be tested in the wild with middleboxes.
But we have an application that can support the cookie in the TLV itself.
Olivier: If there is a consensus of TFO option with zero length we are happy to
adopt that approach. Chris: Test data shows no TFO option is better. Michael
Scharf/chair: Can authors show how BBF and 3GPP are using this protocol?
Mohamed: Preference would be to go Standards Track but would also be okay to
remain experimental.

-       Ongoing implementation effort exists.
-       Chairs will be looking to move to WGLC soon (maybe before next
meeting), but document does need update.

More Accurate ECN Feedback in TCP / ECN++
draft-ietf-tcpm-accurate-ecn, draft-ietf-tcpm-generalized-ecn
Mirja Kuehlewind / Bob Briscoe

-       Make ECN provide better feedback information than classic ECN.
-       AccECN provides more accurate information to the sender.
-       Optional AccECN TCP option to provide more information.

Michael Scharf (from floor): Forward compatibility speculates that AccECN will
the move-forward protocol, but it is only experimental. Bob: Meant to say that
sentence AccECN forward compatibility applies to any future ECN solution.
Gorry: Related to L4S which is also experimental, so there are two experiments
here. Should we be concerned about running these two experiments in parallel?

-       AccECN implementation ported to latest v5.1 Linux kernel.
-       Authors have addressed all comments, and draft has been around for a
while.

No further comments from floor.

-       Document to be updated with minor clarity edits.
-       ~10 people have read current or previous version of document.
-       No concerns from floor about moving document to WGLC soon.

Bob: Overview of bugfix to prevent ECN++ disabling ECN on 84% of servers.

Individual documents

Transmission Control Protocol (TCP) YANG Model
draft-scharf-tcpm-yang-tcp
Michael Scharf

Presented new document in TCPM and raises question on whether WG needs to work
on a YANG model for TCP. -       TCP used by many control and management plane
protocols. -       Requires TCP stack configuration and monitoring on network
elements. -       Some vendors have implemented TCP MIB per RFC 6643, but SNMP
MIBs are being replaced by YANG modules. -       Overview of existing TCP MIB
and mapping to YANG model (mostly read-only/monitoring). -       Question is
whether to do a straightforward replace of the MIBs in RFC 6643 in YANG or
should it be extended as a successor of the MIB.

Mikael Abrahamsson: Statement not question. We’re using YANG to administer
everything – I would like a comprehensive TCP YANG model. Please do not
translate the existing TCP MIB. Lars: Remembers when WG did the MIBs and it was
super-painful. Unless there is a line of operators that want this, I would not
do it as it’s going to be painful. There is almost no commonality across TCP
stacks, which is what makes it hard. Mohamed: We can find a balance. If we see
some existing YANG models such as BGP, it has some generic TCP parameters that
can be re-used. I support this work. Mikael Abrahamsson: I’ll take less if
required (this is not an all-or-nothing deal). There must be a base of baseline
functionality that all stacks share. We can start there. It doesn’t have to be
perfect day one. Lars: This will get very complicated very quickly. It changes
with every kernel version. Re-iterated that we shouldn’t do this. Philipp S.
Tiesel: Looking at this from TAPS perspective, if we could import this stuff it
would be useful. Some discussion with Michael Tuexen around whether this would
make the whole thing more complicated.

-       This is a placeholder and we don’t need to come to conclusion today.
-       Proposal from Michael is to have another talk on this at the next
meeting unless WG believes we should stop any further effort in this.

DNS Transport over TCP - Operational Requirements
draft-ietf-dnsop-dns-tcp-requirements
Duane Wessels

-       Encourages the practice of permitting DNS messages to be carried over
TCP. -       Large responses cause issues – the choice is to fragment or
truncate which means DNS clients need complex retry logic. -       RFC 7766 DNS
Transport over TCP Implementation states that TCP may be used first without
trying UDP but does not make recommendations to operators. -       This draft
encourages operators to ensure that DNS over TCP is on par with UDP and focuses
on the operational requirements. -       Overview and some detail on connection
management/termination.

Praveen: Is there any study about current levels of the use of DNS over TCP?
Duane: There probably are for DNS over TLS – maybe 1% or 2%.
Praveen: Are there any recommendations for using TCP first over UDP?
Duane: No current recommendations.
Tommy: Thanks for doing this. Concern about saying all servers SHOULD use TFO
(perhaps use MAY, and perhaps indicate there are known issues with TFO). Second
comment is to recommend the use of DNS over TLS. Jana: Also suggested using the
MAY wording.

TCP advancements in Windows
Praveen Balasubramanian

Improving TCP stack in windows on nearly 800 million devices running Windows 10.

-       Overview/recap of TCP improvements

Jana: When did you change from compound to cubic?
Praveen: About a year and half back. Latency fluctuations e.g. in virtualized
environments caused compound issues that are much better dealt with by cubic
(in terms of throughput).

-       Improved slow start using HyStart and Limited Slow Start after exit.

Jana: Very interesting. Short discussion on HyStart exit and use of LSS after
HyStart exit.

-       RACK updates: Compliant with draft-ietf-tcpm-rack-04 which has expired.
Request to WG to try and move this document forward on standards track. Chairs
will speak with authors.

Hiren: How does RACK and 3 DUPACK work together?
Praveen: Explanation on use.
Hiren: Have you looked at PRR?
Praveen: Yes, currently looking at it.
Felix: Both loss detection algorithms do you have data on when DUP ACK is
better than RACK? Praveen: No data on which one is better. Randall: Middleboxes
sometimes strip out SACK options, and in that case DUP ACK is better.

-       Lower Initial RTO

Jana: Is there any data to see if initialRTO of 1 second would cause
retransmissions. Praveen: No measured data, but it is possible get statistics
from TCP. Mikael: Is ECN on by default? Praveen: Server is on, client is off.
Mikael: Would you consider setting client to on by default? Praveen: Currently
experimenting with TFO. Mikael: Does this relate to the XBOX stack as well?
Praveen: Yes.

QUIC Loss Detection and Congestion Control
draft-ietf-quic-recovery
Jana Iyengar

QUIC Overview

-       Long header – only used for handshake/session establishment
-       Short header – only has a few fields – used after session establishment.
-       Frames: different types with different sets of fields; note ACK and
STREAM. STREAM carries application data. ACK is acknowledgement. -       QUIC
connection can have multiple streams where each one has a stream ID. STREAM
data has offset field. -       Each Packet may have multiple stream frames, and
each stream frame may have a different stream ID. A packet may even carry
multiple stream frames and an ACK frame. -       ACK frame contains highest
packet number seen so far (not necessarily in sequence), time since largest
ACKed was received, and contiguous ACK ranges.

-       Stream IDs and stream offsets are used to define delivery order.
-       Should ACK every other packet (subject to 25ms delayed ACK timer)

Eric: Is 25msec for an ACK latency fixed and is that short for high-latency
connections? Jana: No impact for high latency connections as this is not
related to RTT.

-       If no ACKs are received, Probe Timeout (PTO) sends 1 or 2 probe
packets. Timeout does not necessarily mean packet loss. When ACK comes back
QUIC does the calculation of packet loss.

Gorry: What does a probe packet contain?
Jana: Suggestion is to send new data.

Praveen: Current draft suggests new data, otherwise highest packet from old
data. Jana: Believe similar text exists in QUIC draft. Hiren: Does QUIC follow
RACK and TLP as per the RACK draft? Jana: No, but we need to look at those
drafts and make sure we are aligned.

End of Meeting.