Minutes IETF117: tcpm: Thu 20:00
minutes-117-tcpm-202307272000-00

Meeting Minutes TCP Maintenance and Minor Extensions (tcpm) WG
Date and time 2023-07-27 20:00
Title Minutes IETF117: tcpm: Thu 20:00
State Active
Other versions markdown
Last updated 2023-08-19

minutes-117-tcpm-202307272000-00

TCPM meeting, IETF-117, San Francisco

Thursday, July 27, 2023 13:00-15:00 UTC-7 (120 mins)

WG Status updates

Time: 15 minutes 15/120

Notetaker: Richard Scheffenegger

Working Group Items

Martin: When you say implemented in Linux, do you mean a private patch,
or in mainline?
Yuchung: Mainline.

Yoshi: How to set cwnd after loss recovery? Has this outstanding issue
been resolved?
Yuchung: Yes. The draft has been updated on that point.

Gorry: How long has the implementation been in Linux?
Yuchung: Every mentioned OS implementations have been upstream.
Gorry: The final version as in this draft has been upstreamed?
Yuchung: Yes for Linux
Richard: Non-bis in FreeBSD for 2 years; -bis improvements to be
upstreamed soon.

Michael: Draft is currently still under WGLC
Yoshi: Please speak up if you have any issues, otherwise will think
about closing the WGLC on this document.

Martin: Giving more feedback is not the issue, it is what you do with
that information which is potentially scary.

Martin: Every time you mention working around IPR I get scared.
Bob: RFC 5981 is challenge ACKs, protection against in window attacks.
Martin: This is probably fine.
Bob: Cisco has IPR on this, one more year to run out.

Bob: Updates on tcpdump decoding AccECN.
Richard: Should be upstreamed next Sunday (2023-07-30).

Michael: WGLC shortly after the IETF, no further.

Richard: Don't pretend that accounting duplicate ACKs is not a brittle
mechanism. ECN++ already states that control packets can only have ECT
when SACK is negotiated. This would be a way forward.

Gorry: Checking the terminology endpoint and host.
Bob: Both mean the same thing.
Gorry: Maybe change them to the same wording.

Matt: Maybe we need to discourage people from using TCP without SACK?
Gorry: Some people want to put small footprint in TCP. Everybody else
uses SACK.
Christian: Or rather, either do SACK or keep the window very small...

Michael: The plan is to finish work on AccECN and first and then focus
on ECN++.

Ian: Clarification Question: Zero in the R value means ACK only this
packet, while One means ACK on this, and every subsequent packet?
Carles: Correct.

Christian: QUIC delay ack draft - one part in QUIC but not in TCP: If
the receiver sees a stream of packets where there is probably packet
loss, in QUIC it is easy. The idea is if the receiver sees loss, then it
makes sense to send an ACK immediately. You may want to add text
discussing this kind of stuff.

Ian: I'll wordsmith it a little bit, send me an email for how to say it
best.

Yoshi: personally would like to use normative language here. Because ACK
frequency is larger than window size, ACK sampling rate lower, in most
case this can have many bad side effects. Seems to be better to provide
strong guidance.

Carlos: Do you prefer normative language?
Yoshi: Yes, SHOULD. As we want to override it in some case.
Ian: This is a difficult subject. I prefer not to have normative
language. Additional question if normative language around round trip,
or congestion window. The sender knowns the cwnd. Recommendation to not
set it larger than the cwnd on the sender side. Would like to ideally
see reasonable synchronization between this work and QUIC.
Martin: Keeping AckCC and QUIC in sync is challenging as different ADs.
Please give rapid feedback directly between the two WGs involved. We
could set up a reference/dependence thing. Keep talking to each other is
the best current option.

Neal: Can you share the status of any implementations?
Carlos: Only aware of some prototypes done on FreeBSD.

Yuchung: How does this option work with LRO - the receiver sees jumbo
data segments. What happens in that scenario?
Carlos: Text talks about segments without their size.
Yuchung: First you sent MSS segments but the receiver may only see very
large jumbos. Does it send two ACKs immediately, back to back.
Carlos: No particular text in the draft. We need to consider this
particular case.
Yuchung: Back to back ACKs seem to be wasteful. How much benefit would
this draft provide over a simple option that just tells the receiver not
to delay any ACK.

Carlos: The sender is not in control, the receiver can always ignore the
request.
Neal: Really important in DC environment, workloads fair share of BDP is
1 packet or less. In these cases Linux is dependent on a heuristic with
the CWR bit triggering an immediate ACK. AccECN no longer has this kind
of signal possibility. It is important for the sender to say that cwnd
is very small.

Yuchung: This seems to be a big change.
Stuart: Echo Neal - opposite context. One of the reasons I want is
constraint IOT devices, they only have memory for 1 packet, can not hold
more - wait for delayed ACK on every RTT. Use case is to say please ack
every packet or I stall for the DelayedACK.

Yuchung: Using a new option may not be the optimal way.
Richard: There are heuristics to ACK on PSH. One could come up with a
draft documenting this use when small cwnds are the only concern.

Martin: This is all Crazy talk. But future ack filters could use this
constructively to not ruin everything.

Other Items

Richard: MSS clamping is problematic; not sure what a specific bit gains
as the MSS will be hidden from legacy middleboxes.
Michael: MSS is different from the others - middleboxes want to deal
with that, leave it as a separate option. Do not aggregate MSS into this
aggregated option.

Michael: I still not think to aggregate MSS option is good. Look at what
values are used by syncookies. This is default is several TCP stacks.

Matt: MSS is all over the net, astonished how many different values are
in use today. Public data.

Martin: Around MSS: Attractive as I don't use the dumb default, use
modern default. Would they add it or not.

Michael: If a middlebox can not clamp, PMTUD is required.
Martin: Interesting to see what happens.
Michael: Guessing the right value is very hard.

Matt: A larger and larger fraction of just ordinary traffic is being
tunneled. There is no single good value.

Richard: If you send late MSS option, investigate what deployed
middleboxes doing MSS clamping are actually doing.

Martin: Option space is a tradeoff - accept that the older options are
is loosing the older options worth loosing performance. If this fails
you loose an RTT. The deployment scenarios should be thought a bit more.

Tim: How do I know if the other end supports this. Do I include both.
Yoshi: Initially you include both, and remember for subsequent
connections.
Tim: Didn't see this prominently in the draft around that.

Lars: Around MSS: This option is extensible - take the MSS aspect out
for now, and leave it for later. Its about how to get this rolled out.
If you don't know what the other host is doing. It feels like doing a
step back against doing a step forward.

Yuchung: How many of them are truly necessary. SACK could be used
without SACKOK. If the receiver of the option wants to use it, use it.
Yoshi: it would have to update the SACK RFC.