Minutes IETF115: tcpm
minutes-115-tcpm-00

TCPM meeting, IETF-115, London

Wednesday, November 9, 2022 13:00-14:30 UTC (90 mins)

Notetaker: Richard Scheffenegger

WG Status updates
-------------------------------------------------
 Time: 15 minutes                                                       15/90

EDO:
Gorry: Ok, if there is intent to implement, if there is no intent why not make
this EXP. Martin D: Why PS, if noone wants to implement or deploy. Michael T:
There are discussions in the RFC of what NOT to do, in addition to the way how
it may be done. Martin D: Great, but that would be a INFO RFC. Lars: It asks
for an option number - if standard actions is required (IANA codepoint) this
may a reason to go with PS.

Working Group Items
-------------------------------------------------

* Status of AccECN
  https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-19
  Speaker: Bob Briscoe
  Time: 15 mins                                                         30/90

Ian S: What is the expected deployment ratio btw AccECN option and the header
only ACE counter? Bob: Option is to help with middleboxes, wide area;
datacenter you would probably only go with the ACE counter. Martin: Is the
AccECN option tested across the internet? Bob: Interop testing was locally
only. Michael: We did testing between test lab in germany and the the IETF
network. Bob: Did a lot of testing and investigation on option viability a
couple years ago - there are papers about this. Although this is not recent
testing. Christian: What happens on a path change during the negotiation? Bob:
Handshake checks for bit mangling and path conformance - but not continually.
At the moment, bleaching is in the first few hops. Could happen. But AccECN is
a lot better than 3168, as it checks at all. If ECN is mangled - there is loss
and CC will react to that. Lars: In QUIC we found the last hop was mangling.
Richard: Had validated AccECN bits and option in previous IETF L4S interop
testing - with expected (non-AccECN handshake on bleaching) results. Gorry:
Mangling tests have complicated the draft. There is text in there - please read
the draft.

Other Items
-------------------------------------------------

* Future Status of RFC 3465

  Speaker: Martin Duke
  Time: 10 mins                                                         40/90

Ian: BBR may be standardized. The SS algo is not HyStart++. What do we do with
that? Martin: First, BBR is far from standardized. SS/CA model may be outdated
by the BBR mechanism. So you don't need to rely on this document. Michael: What
if in the future, people are not using HyStart++. Would like to have a future
proof document. Martin: Is the consensus, that this is not the best practise.
If you redefine slow start, you don't necessarily a doc downrev issue. Michael:
That can specify whatever they want? Martin: Correct. Lars: Option: open up
5681 and have a bigger discussion around these topics. Martin: This scales the
work up to 11. Unless someone takes up this task, this would be much larger
task. Christian: I am with Lars and Michael with this discussion. It may be a
mistake to specify the implementation. The intent of slow start is to avoid big
overflows. Clear that HyStart does that. Other ways exist too. Much better to
state principles rather than specific solutions. Martin: Are you volunteering?
Christina: Aahhe.. no. Martin: Don't have the bandwidth to do this. Gorry: I
may prefer option 1. Algo is an algo - we know we need to do something, but not
yet what exactly. Michael Welzl: Maybe point 3, but with a SHOULD. Text in
there to explain this. Michael T: It focuses on L=8. Martin: Yes, gives advice
to use 8 if you don't know what else to pick. Martin: Action Item: No
enthusiastic support, probably do nothing at this time. Ian: Poll: 9/12 to have
a PS document in this space - fewer people in this room participated. Lars: No
sense of urgency - motivates the passiveness. Christian: Should this be in
CONGRESS? Martin: Ah, yes may be a good idea.

* TCP ACK Rate Request
  https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-rate-request-06
  Speaker: Carles Gomez
  Time: 10 mins                                                         50/90

WG adoption poll: 21 persons raised hand, out of 24.
Michio: Why is this is really needed. PSH is triggering an ACK in the
datacenter use case. Michael: PUSH is not specific on the receiver side. For
example, FreeBSD does not trigger an ACK on PSH. Gorry: Concerned. ACK
mangling, QUIC we understand that. With TCP not so sure. Is there understanding
what the network does 3449 with this option. Mirja: Christian: On TARR: if we
do something for controlling ack rate in TCP, should we try to keep common
concepts with the delayed ack option in QUIC? This would help building common
experience, etc. Jonathan: This is not what the semantics of the PUSH flag are
defined for. [misusing to trigger ACK]

* TCP Service Affinity Option
  https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp-service-affinity-option-00
  Speaker: Wei Wang/Aijun Wang
  Time: 10 mins                                                         60/90

Lars: I feel this is the wrong level to solve this problem. Always have to deal
with legacy clients. Also, the network can change these signalling - a long
number of things why this may be better to solve this in higher layers. Wei
Wang: Problems in real-time processing of higher layers in the load balancer.
Aijun Wang: Our solution is a hybrid solution between network, client and
server. Bob: I tend to agree with Lars. First hash this info, cookie in the
option. SYN-Cookie with more information in the SYN Cookie - allows you to get
soft-state. There are things you can do so that clients would do this. Ian: I
also agree with Lars. Serious policy concerns about how this is structured.
SYN-Cookies would be preferred. Draft would need to be seriously changed to
conform with IETF process.

* Analysis for the Differences Between Standard Congestion Control Schemes
  https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-standard-cc-analysis-00
  Speaker: Yoshifumi Nishida
  Time: 15 mins                                                         75/90

Martin: 9002 is the best current practise, which we probably agree upon now.
Lars: Thanks for doing the work about the differences. We deliberated over all
of these chances - I would argue that 9002 more accurately reflects the current
thinking. Thanks for this starting point for further discussion. Martin: 568