* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tcpm Status Pages

TCP Maintenance and Minor Extensions (Active WG)
Tsv Area: Mirja Kühlewind, Magnus Westerlund | 2004-Feb-05 —  
Chairs
 
 
 


IETF-104 tcpm minutes

Session 2019-03-25 1350-1550: Grand Ballroom - Audio stream - tcpm chatroom

Minutes

minutes-104-tcpm-02 minutes



          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.
          
          



Generated from PyHt script /wg/tcpm/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -