Minutes IETF112: tcpm
minutes-112-tcpm-01

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!