The sender (peer) will not generate an RTT sample in scenario A, see Section 5.1 of RFC 9002: https://www.rfc-editor.org/rfc/rfc9002.html#name-generating-rtt-samples
In scenario B, the RTT sample is inflated by design: https://www.rfc-editor.org/rfc/rfc9002.html#section-5.3-5 /me -------- Original Message -------- From: Martin Thomson <[email protected]> Subject: [Editorial Errata Reported] RFC9000 (8106) Date: Tue, 17 Sep 2024 14:43:48 +0200 (Central European Summer Time) 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.
