Minutes IETF116: tcpm: Mon 06:30
minutes-116-tcpm-202303270630-01

TCPM meeting, IETF-113, hybrid

Monday, March 27, 2023 15:30-17:00 JST (90 mins)

Notetaker: Momoka Yamamoto, Eric Gorbaty

WG Status updates

Time: 15 minutes

Working Group Items

AccECN and ECN++ updates

https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/
Speaker: Bob Briscoe
Time: 20 mins

On Markku review:

Brian Trammell: It's probably sufficient to say "additional combinations
of these bit fields may be allocated by IANA subject to Standards
Action"

Mirja Kühlewind: I don’t think we need to create a registry. So I would
say no need to mention IANA

Richard Scheffenegger: We've had the discussion around ACK-on-ACK (which
really may only happen with ACK++ as mentioned). I don't buy the idea of
it causing data segment retransmissions.

Richard Scheffenegger: Since any new data packet will get an ACK (with
the most recent ACE counter), breaking any "chain" of "continuous
retransmissions"...
(Received indications of a vendor interested in getting AccECN deployed
in production "soon", based off the FreeBSD stack... Maybe in
conjunction with iOS/MacOS support).

Brian Trammell: Mirja/Bob: if the TCP flags aren't already somehow in an
IANA registry, then agree -- no need to involve IANA. haven't checked
though. if the flags are already mentioned in an IANA registry then
there's probably a (admittedly, potentially pedantic) need to inform
them via this draft.

I don't think there is though (checking via RFC 7125) so yeah, agree
with Mirja, no need to invoke IANA on ACE.

Questions:

Michael Tüxen: Clarification. Is it part of kernel?

Bob: It's not in upstream yet. That's in progress. Ilpo is helping.

Markku Kojo: But but the problem is that if this feature causes for fast
retransmit, it's problem. And then it would say, should not use without
by timestamps or SACK enabled. It would say must not use. Because there
it also interface or confuse this auth recovery. Confuses limited
transmit confuses, PRR, it causes extra packets for making this more
aggressive than it is supposed to be. And it breaks FRTO and Eifel. It
requires quite a complicated scenario, but still there is area or maybe
more than once scenarios where it breaks it.

Richard: We've discussed it about 6 month ago already. If you have some
specific scenarios that cause issues, please let us know.

Markku: I will.

Mirja Kühlewind: Do you agree this is the problem for ECN++ as we don't
see this issue without ECN++.

Markku: But, this draft specifies the logic.

Bob: I indicated agree with you Mirja, but what the AccECN draft says
about ack on ack cannot be applied unless you're also putting the ECN
capability on pure ACKs. You wouldn't be acknowledging them unless they
had ECN capability, which is why I'm suggesting we move it in ECN++. The
AccECN describes simple requirements and refer ECN++ for the detailed
logics.

Yoshifumi: ECN++ is experimental. I think you should make that clear in
this draft. That's might be useful.

TCP ACK Rate Request

https://datatracker.ietf.org/doc/draft-ietf-tcpm-ack-rate-request/
Speaker: Carles Gomez
Time: 15 mins

Gorry: Do you have data that 1 ack per RTT doesn't has positive
performance?

Carles Gomez(presenter): We will try to get some data.

Mirja Kühlewind: There is a similar discussion in QUIC about this. have
concerns about bursting/pacing without using normative language.

Carles Gomez(presenter): OK. Will add some normative language there.

Yoshifumi (as individual): So let's say we set 5 or 6 to R, a bit big
value. If timeout out happened here, then congestion window becomes one.
In this case, if the receiver still thinks R is 5 or 6, then the
performance will be degraded. What do you think about this case?

Carles Gomez(presenter): That's a good point. A safety mechanism is
needed.

Richard Scheffenegger: A more generic description would be useful as the
TARR option is under the sender's control. Rather than describe each
specific instance (e.g. slow start, RTO, ...) provide guidance that the
sender should be choosing a TARR value appropriate on what the sender
requires at that moment.

Bob Briscoe: if we specify specific ABC behavior, it might not be an
experimental doc anymore.

Other Items

Service Affinity Solution for TCP based Application in Anycast Situation

https://datatracker.ietf.org/doc/draft-wang-tcpm-tcp-service-affinity-option/

Speaker: Wei Wang/Aijun Wang
Time: 15 mins

Yoshifumi (as individual): This seems to be a broad concept such as TCP
connection migration and service affinity is one use case for it. I
might prefer a different option name because of it. Also, there are
possible security concerns associated with the connection migration
based on what has been suggested, primarily via having the ability to
steal connections.

Wei Wang: We hope to improve in security areas. Hope to get more
feedback.

Aijun Wang: Gave further clarification on security concerns, has some
ideas on how the current approach meets some security requirements.

Mirja Kühlewind: I see your need. But the security problem is very big,
not sure we can solve it with a TCP option.

Wei Wang: The security concerns have been noted.

Ian Swett (as individual): A question is this proposal is at the right
layer as this seems very difficult to deploy.

Lars Eggert: Expressed some doubts about the interest in adoption here,
interested in understanding what questions need to be asked in order for
this to change, since the trajectory has been that the sufficient
interest or implementations are not evident.

Yoshifumi: What do you want to see in the future version of the draft?

Lars: ideally, I would like to see interests from implementors and
people want to deploy it.

Mirja Kühlewind: Further clarified concerns about security, indicating
that this adds extra vulnerability on top of TCP which is already
vulnerable, doesn't think that a solution is to be found as a TCP
option, and standardization will be impossible that way. I recommend you
to think about a completely different solution to solve this issue.

Aggregated Option for SYN Option Space Extension

https://datatracker.ietf.org/doc/draft-nishida-tcpm-agg-syn-ext/
Speaker: Yoshifumi Nishida
Time: 15 mins

Lars: (clarification). We have UTO as an example for not using SYNs.

Lars: Do we have an option that is cached between connection instances?

Ian: TFO?

Lars: True. That might be only use case.

Yoshifumi: How about MSS?

Lars: I'm concerning the case where caching info was for different
nodes.

Andrew McGregor: It't not a problem for large operators that use load
balancers.

Richard Scheffenegger: I would like to see some benefits for applying
this to MSS and window scale options.

Martin Duke: Very intrigued. Doesn't have a lot of the difficult
consequences of some of the other option space solutions that that
people come up with. So this is great.

Lars: There might be a solution that was not possible before as the
world is changing.