On Tue, Sep 17, 2024, at 08:02, Lars Eggert wrote:
> huh. I always thought that non-ack-eliciting packet need not be ACK'ed
> *at all*, but that any sent ACKs (whether for ack-eliciting or
> non-ack-eliciting packets) would need to be sent within the max ACK
> delay.
>
> Because if we allow non-ack-eliciting packets to be ACK'ed later than
> the max ACK delay, doesn't that inflate the RTT samples? (Because we
> only subtract out max_ack_delay?)
Ah, I see. There is an inconsistency. But maybe the fix is in the other
direction.
That is, if you receive a non-ack-eliciting packet, you can sit on it for ages.
If you do decide to send an ACK, you report how long you sat on it for.
That requires that the logic in RFC 9002, Section 5.3 would be the piece that
is in error. You would only cap the reported ack delay by the max ack delay
for ack-eliciting packets.
Otherwise, yes, you are right, the right thing to do is acknowledge within max
ack delay, regardless.
I think that fails to produce a good RTT estimate if the ACK is lost, but
that's true of any lost ACK anyway.
Let's take an example or two of where the current logic falls down:
0. The starting condition is that you acknowledge unacknowledged packets when
you send a packet. That's pretty normal logic, I should think.
Scenario A - ACK after long delay
1. You receive a non-ack-eliciting packet.
2. Some time later, but after the max ack delay, you acknowledge it. Maybe
because you needed to send something else. You report the delay in ACK as
normal (that is >MAD).
3. Your peer receives an RTT sample that inflates its RTT estimate
unnecessarily because of the delay.
Scenario B - Loss
1. You receive a packet.
2. You send an acknowledgment promptly, but that is lost.
3. Later, you have cause to send a packet and - because the ACK has not been
acknowledged - you send another ACK, reporting the longer delay.
4. Your peer receives an RTT sample that inflates its RTT estimate
unnecessarily because of the loss.
In Scenario A, conditioning the capping of the RTT sample on whether it is
ack-eliciting avoids the inflation of the RTT estimate.
In Scenario B, the packet might have been ack-eliciting, so that conditioning
would not help. The only remedy there is to accept some inflation due to loss,
and hope that the running average keeps the inflation from being too extreme.
That might be OK for flows with low loss rates.
However, Scenario A seems pretty likely, especially for some traffic patterns,
so it seems like maybe something could be improved.
