Re: [tcpm] Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

["Scheffenegger, Richard" <[e-mail]>]

Hi Mirjy, Vidhi,

>> Sure. But if the sender (who was receiver before) has already sent out data right after the pure ACKs, there will be outstanding data before the ACK for pure ACK (or DupACK as there is outstanding data) is received from the peer, right?
>
> I see. That means you send a whole bunch of Pure ACKs and then some data in the same RTT. In this case it would actually be nicer to wait for the data packet instead of sending a pure ACKs. Maybe should should rather use always some thing like a delayed ACK timer for pure ACK rather then saying we need to ACK each nth pure ACH?

Introducting an additional delay is further reducing the risk. (And it
would be relatively easy to implement, reusing existing functions.) But
remember we started out with the (unlikely, and rather pathological
corner case, where a re-routing event coincides with when the ACKs get
sent out, redirecting them over a path which marks near 100% of these
very small pure ACKs with CE - while the former sender has send a window
of packets of size 3*n (at least).

And yes, slightly holding off for sending the ACKs-for-CE-marked-ACKs
(e.g. activating the delayed ACK timer, or when the n+1'th CE-marked ACK
is received) further reduces the probability to trigger this.

As will the use of SACK and TSopt (I don't know recent numbers, but
suspect that a vast majority of TCP flows is currently used one or the
other (or both) of these TCP options.

All that, to avoid a spurious Retransmission (spurious retransmissions
do happen currently much more often for much more begning reasons, like
RTT step changes) - while the congestion control reaction is actually
the intended, and correct behavior. So that non-SACK (non-TS) sender is
only "behind" by one segment, which may have been a new data segement
instead...

I suspect this discussion is really about the mite-hole at the end of an
ant-hole, at the end of a rat-hole, at the end of a rabbit-hole ;)

At least I can not think of a realistic scenario, which is expected to
be encountered in a future L4S/SCE (shallow, instanteous marking)
environment, that would run into such a pathological setup on a regular
basis. But perhaps there are some...

(Extremely high RTT, very large BDP links, with cwnd measured in 100s of
segments, and extreme congestion of a shared-use return path, perhaps?
Still not convinced that here the marking will hit dominantely pure ACKs
(and not data segments of significantly larger size), and in
sufficiently high number to cross the 3*n (or, with delay, 4*n) threshold.

Yoshi, do you have a scenario in mind, where this effect may be relevant
or even dominant?

Best regards,
    Richard