Minutes IETF118: tcpm: Mon 14:30
minutes-118-tcpm-202311061430-00

TCPM meeting, IETF-118, Prague
Monday, November 6, 2023 15:30-17:00
3 Chairs
Notetaker: Gorry Fairhurst

1. WG Status updates including rechartering

Document status was reviewed by the Chairs.
Accurate ECN is being advanced to the AD - there are additional comments
to be provided by M Kojo and their may be last comments that might need
to be taken into account before the document is progressed. The chairs
will work with the AD.

Generalized ECN is near WGLC.

The new proposed charter was discussed. The group discussed where CC
work would land, and this would normally be in CCWG. Other topics could
still need liaison between groups.

1. Working Group Items

• Status of Generalized ECN / ECN++
  https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-14

  Speaker: Bob Briscoe

Michael Tuexen: There is intention to restart the work on SCTP with ECN.
The draft has been revived, but the content has not yet been updated.
Bob: Then ought I to not comment this old ID?
Michael: Yes.
Gorry: As TSVWG Chair: I think you can still refer to the SCTP base
spec as not defining ECN and say there is work-in-progress on ECN for
SCTP.

Martin Duke: Is Marku's comment about just this?
Chairs: It is about ACKs of ACKs. He has promised new text.
Martin: I will wait 24 hours.

Reviewers: Gorry (must review as WG responsible for ECN); Mirja will
review; Bob will look for others.

• Status of ACK Rate Request
  https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ack-rate-request-03

  Speaker: Carles Gomez

  Gorry: Why 1-4 RTTs in the draft?
  Ian: I think the proposal was to change this 1-4 ACKs per RTT.
  Gorry: Aha, that was not what I read, that does seem to reflect what
  was talked about in QUIC, so this is likely an editorial issue, we
  can follow-up on the list.

  Gorry: You say in some places for not do things because of an RWIN
  limit. But, can't the RWIN change at any time, so is this really a
  thing that can be used to decide when to update the ACK policy?
  Carles: I'd like to discuss on the list.
  Gorry: Sure, that would be good.

  Bob: There are various conditions that trigger an ACK. This is
  called out in Specs.
  Carles: The intention was not to change these specs.

• EDO on Linux
  https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-13
  Speaker: Kuniyuki Iwashima (remote)

  Ian: Is the intent that this is a temp problem needing GSO to be
  disabled?
  Kuniyuki: The intention is to support GSO and GRO in future.

  Michael Tuexen: Is the baseline without LRO, etc.
  Kuniyuki: Yes.

  Martin: Thanks for presenting this. I have been curious about this
  for 2 decades. What is the most important use case - do you have one
  in mind?
  Kuniyuki: I think there are cases that need more than 40 bytes of
  options.

  Martin: Did you observe any odd middlebox behaviour on the network?

  Kuniyuki: Not used on the Internet yet.

  Yoshifumi: This could be useful when using a combinations of
  options, e.f. MPTCP and AO or using many SACK blocks.
  Martin: I see, and maybe this could live with fewer SACK blocks.

  Wolfgang: How is the EDI portion counted - is the extended option
  counted as window size?
  Kuniyuki: No.

  Matt: I am aware of NATs that rewrite payloads (e.g., the FTP
  control channel) that can result in segmented packets. Someone can
  check if these are common?

  Ian: There could be security considerations for long lists of
  options, I think this ought to be in the draft.

  Yoshifumi (as Chair): Now, we have an implementations of EDO. Do we
  have any blockers of this draft?
  Michael Tuexen: Please send comments to the editors using the
  mailing list, so they can respond and learn from what we have seen
  presented today.

1. Other Items

• RFC 5681bis (TCP CC) / RFC 3465bis (ABC)
  Speaker: Martin Duke

  Martin: Lars is expecting to open an edit on this, if people are
  willing to help. Please volunteer to help. I plan to keep talking
  about this.

• Opportunistic TCP-AO with TLS
  https://datatracker.ietf.org/doc/html/draft-piraux-tcp-ao-tls-00
  Speaker: Maxime Piraux

  Yoshifumi: What will happen if there is a partial failure? When the
  server does not support TCP-AO?
  Maxime: The server should not enable AO, it could be solved if the
  draft is updated to consider this.

  Michael: What is the interaction with TLS key updates?
  Maxime: The key updates do not update the master secret, and we
  don't think we should synch the TLS key updates. At the moment there
  is no impact, but at some time you need to update the AO keys. We
  need to think more.
  Michael: We have similar concerns with SCTP key updates over long
  sessions.

• TCP FWA: Fast Window Advance for TCP
  https://datatracker.ietf.org/doc/html/draft-thejeswara-tcpm-tcp-fwa-01

  Speaker: Thejeswara Reddy (remote)

  This concerns messages (e.g., SIP over TCP), which can result in old
  data being held when the cwnd reduces.

  Altanai: In some connections a SIP might wnat to ressue SIP
  requests, how will this work?
  Thejeswara: This is controlled by the application.
  Igor L: For bulk transmission, you can have filled the entire
  receive buffer, so you need to wait at least one RTT to clear this
  buffer. How does this look for a regular receiver? what is the user
  interface?
  Thejeswara: Yes, requires one RTT.
  Thejeswara: The interface looks the same.
  Igor: The TCP receiver recieves a byte stream, how does it know
  about the gap?
  Thejeswara: The receiver does not see the sequence number.
  Igor: I am unsure this is usable.
  Bob: Do we need to use a TCP flag for this? Can we overide other
  flags such as URG or PSH in combination to make more codepoints.
  Chairs: Let's first see how useful this is. Please continue to
  discuss on the list.