* 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: Zaheduzzaman Sarker, Martin Duke | 2004-Feb-05 —  
Chairs
 
 
 


IETF-112 tcpm minutes


Minutes

minutes-112-tcpm-01 minutes



          TCPM meeting, IETF-112, online
          Thursday, November 11, 2021, 12:00 - 14:00 UTC (120 mins)
          WG Chairs: M. Scharf, Y. Nishida, M. Tuexen
          Note Taker: Gorry Fairhurst
          
          1. WG Status Updates
          
          Agenda presented, no changes requested.
          
          draft-ietf-tcpm-rfc793bis is now in IESG Evaluation::Revised I-D Needed.
          Some review comments could benefit from discussion on the list, Wes will
          post emails as needed.
          
          HyStart++ is being implemented and will be presented next meeting.
          
          This meeting might be Michael Scharf's last one as a Chair, the plan is
          to step down after RFC793.bis is processed.
          
          2. Working Group Items
          
          2.1 RFC 6937bis: Proportional Rate Reduction for TCP
            https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-01
            Speaker: Yuchung Cheng (proxied by Chairs)
          
          Authors plan to submit a new revision for the next IETF meeting.
          Yoshifumi noted there were changes and asked if the changes were already
          in mainline.
          Neal C.: I believe the .bis will reflect the changes and will cover
          logic in Linux TCP
          Richard S.: Upcoming revision of BSD will address this, and have provided
          comments to authors.
          
          2.2 RFC 8312 bis: CUBIC for Fast and Long-Distance Networks
            https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-05
            Speaker: Vidhi Goel
          
          Issues being tracked in github and are being addressed.
          There have been recent changes, see slides.
          There are Open Issues considering spurious congestion events.
          Plese read and send comments to the list.
          Stuart Cheshire: Noted there could be wireless issues from a sudden
          reduction in capacity, where Cubic took many RTTs to make a x10 reduction
          in rate.
          Praveen B.: Are the changes being made also reflected in the stacks
          being implemented today?
          Vidhi: We are trying to allow options, and avoid requiring changes. The
          ECN change (see slides) is one that ought to be changed - this reflects
          not just Linux, but other cases too.
          Neal C.: I'd like to encourage keeping the text on "undo" of variables
          after spurious ordering detection. Regarding cellular and Wireless -
          we didn't generally see losses from wireless segments so agree with
          Stuart about the main effect being physical layer rate changes.
          Lars E.: The main motivation was to document what was
          implemented. Markku's review noted places of conflict with the RFC
          Series. I think some of the changes reflect actual deployed code, rather
          than the previously specified methods.
          Ian S.: I think we should be careful to not include things that are
          required, but not implemented.
          Michael T.: I would note the differences between what major
          implementations do not want to do, and what they may implement in future.
          Vidhi: On using 'cwnd' instead of Flight_Size wasn't documented in the
          RFC series, so we needed to be careful.
          Lars: The current cubic draft updates an RFC that is PS.
          Michael T.: This normatively uses HyStart++ (SHOULD), and this is
          a dependency.
          Lars: HyStart++ is the only standards-track spec. in that space.
          Praveen: We're looking for others to implement the update to the latest
          spec., and hope to see this go to WGLC soon.
          
          Chairs: We expect to ask the WG to confirm the changes to the final
          version.
          
          2.3 TCP YANG model - update
            https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-04
            Speaker: Michael Scharf
          
          Upcoming changes in -05. Suggest documenting differences with draft
          opsawg-l3sm-l3nm, and could add a new appendix to differentiate with
          the TCP-MIB (RFC4022).
          
          Martin Duke: What is the reasoning behind doing the comparison with the
          TCP MIB?
          Michael S: For those already implementing the MIB, this could help and
          understand the differences.
          
          2.4 TCP-AO Test Vectors draft status
            https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ao-test-vectors-02
            Speaker: Juhamatti Kuusisaari
          
          Chairs: Please review and send comments, we are considering a WGLC for
          INFO RFC.
          
          2.5 TCP-AO Interop
            Speaker: Greg Hankins
          
            Neil C: It seems over the past couple of months there are Linux
            contributions for TCP-AO.
            Michael S.: Did you look at the test vectors? It would be excellent
            to know if the vectors work.
            Michael T.: Do you know if the BSD implementation is to the base stack
            or some other?
            Greg H.: I will follow-up on these.
          
          2.6 TCP EDO/EOS
            https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-11
            https://datatracker.ietf.org/doc/html/draft-touch-tcpm-tcp-syn-ext-opt-10
            Speaker: Joe Touch (proxied by Chairs)
          
          TCP-EDO thought by editor to be ready for WGLC, and the second to be
          discussed.
          Wes: This seems stable and no known issues to us.
          Yoshifumi: I'm curious about middlebox interactions. As an individual,
          I would like to see the suitability of the SYN draft as a work item
          rather than individual. I will send comments.
          Martin D.: Are there any implementations?
          Wes: There was some work on EDO that provided feedback to the design,
          but no code ready to upstream. There is no driving need at this time to
          do this, but people have in the past asked for this. I think WGLC might
          detect if there are further inputs.
          Michael S. (as an individual): There was a strong need only a few years
          ago - we can't know the future, so documentation is useful.
          Martin D. (as an individual): Does EDO need to be standards track,
          wouldn't it need experimental experience?
          
          3. Other Items
          
          3.1 Updating RFC 5681
            Speaker: Lars Eggert
          
          Should we do a revison, and should make this a full standard?
          
          Mirja K.: I think these changes need to be done first.
          Martin D.: I wonder about the ABC.bis? A full Internet Standard will be
          hard to modify.
          Praveen: The changes make sense to me. Not baking this in an Internet
          Standard makes sense. What are the other issues we want to do apart from
          the ssthresh change?
          Lars: I think we should start a short list.
          Gorry F.: I did try to catalogue what the RFC Series says about CC
          good practice in a TSVWG draft. There's quite a lot and it doesn't all
          sit well with current practice. I think we need to be careful about
          what we standardise, and think whether we can make claims across all
          transports/CCs.
          Bob B.: The changes on this slide are fine. Moving to Internet Standard
          isn't: RFC5681 Reno has low and reducing usage, while other CC's are
          taking over from it. So it would be odd to move such an algorithm to
          Internet Standard.
          Michael S.: 793.bis has a section with basic congestion control
          requirements. That changes the framing and may have some (editoral)
          impact on a 5681.bis.
          Chairs: Please take this discussion to the list.
          
          3.2 Updating Appropriate Byte Counting (ABC)
            Speaker: Vidhi Goel
          
          Stretch ACKs>2 are common. Looking at removing the limit of 'L' in ABC
          and instead advocate pacing.
          Martin D.: I think we should update 5681 to do this. Mark Allman should
          be included in the loop and we should discuss what is safe on the list.
          Praveen: The Windows stack does not by default do pacing, and does
          do L=8. I think Linux does not pace TCP. This is a nuanced discussion
          about pacing.
          Vidhi: We have not reached consensus on this in the past. Without pacing,
          we could use a different 'L=10'.
          Ian S: RFC9002 says Senders MUST either use pacing or limit such
          bursts. Choice of '10' comes from the IW=10 EXP spec. It's a number that
          already exists.
          Praveen: '10' might be as good as '8'.
          Vidhi: The point we need to focus on is whether you can burst a cwnd in
          a single send?
          Yoshi: I think ABC doesn't specify the behavior during recovery phase. So,
          dup ack handling is only for reorder case?
          Vidhi: Right. it mentions about RTO cases, but doesn't specify the cases
          for fast retransmission.
          Chairs: Please continue this discussion on the list.
          
          3.3 TCP Silent Close: For Cases Where Silence is Golden
            Speaker: Neal Cardwell
          
          Mirja K.: There seems a tradeoff here, I am not sure how the tradeoff
          is decided.
          Neil C.: This is mainly about middlebox memory, and the state can be
          recovered by garbage collection.
          Michael T.: If the app shuts down the read, should the TCP connection
          go away?
          Stuart C: I think the considerations need to be considered for NAPT and
          firewalls because TCP's state is recovered by the FIN/RST and that enables
          a longer timeout. Forcing more aggressive scavenging by middleboxes can
          motivate sending more keep-alive traffic, and that will have implications
          on the future mappings for UDP. If we make remove TCP FINs, we may see
          similar issues like in UDP bindings.
          Ingemar (via Jabber): Has this problem been identified by operators /
          vendors ?
          
          Chairs: Thanks for attending and keep discussing on the list!
          
          



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