Hi, On Sep 17, 2024, at 15:43, Martin Thomson <[email protected]> wrote: > 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.
maybe I'm missing something, but isn't the ACK delay encoded in an ACK frame (only) the delay of the largest ACK'ed packet number? How would you disambiguate between ack-eliciting and non-ack-eliciting packet numbers when you parse an ACK? (I'm probably missing something. Need coffee.) Lars > 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.
signature.asc
Description: Message signed with OpenPGP
