Change:
Works for me, so I consider this issue resolved.
In Section 5.3: I don't understand the motivation behind this statement. Assuming that the peer is measuring their actual ackdelay, i.e. it has a sample for arrivaltime[psnhighestacked] and then when creating the ack and calculating the ackdelay it will do time(now) - arrivaltime[psnhighestacked] and that is then larger than maxackdelay. Then this has nothing to do with the path, only with the peer implementation and its capability of waking up to report the ack when additional reception is not forcing it to ACK earlier than maxackdelay. Thus, by capping the use of ackdelay to maxack_delay then in certain transmission conditions the RTT will be inflated, and in others not. I would guess that the impact of this is in most cases minimal. However, from a factual stand point it appear to me as non true statement. Does this needs be changed?
Right, it is not a direct function of the path, but it is included in the path delay as represented by the RTT estimates. I'm not sure of a better way to say this, but NAME might have a suggestion.
NAME : Yes, that is correct, and that is exactly the intention. What is not intentional delay at the peer is considered part of the "path". The model we have is as follows. A sender wants to separate intentional delays at the peer from unintentional delays, since it can then do a better estimate for loss detection by not counting the ack delay in the EWMA. This leads to an issue where the peer can intentionally or unintentionally misreport actual ack delays, causing the estimated RTT to be incorrectly small. To avoid this, we have two checks: all RTT samples, after adjusting for ack delay, are limited to being the measured min RTT, and any reported ack delay has to be smaller than the peer's promised max ack delay. The question here is not whether the unintentional delay belongs in the path or not, but whether it ought to be removed from the path RTT, since we explicitly remove the reported ack delay from the RTT sample. Since this is unintentional (or uncontrolled) delay, we consider it part of the path, and part of the EWMA.
NAME do these explanation address your issue? Or are text changes required?
NAME my point is that an error in timers waking up the receiver to send an ACK will affect the time of the transmission of the ACK. However, in those cases where at the time it wakes up to construct the ACK it correctly reads the time and accurately represent the time between the time of packet reception and transmission of ACK in the ACK_DELAY field the RTT is correctly estimated. It is the timing of the feedback loop that is a bit in error as it was longer than max ACK delay. To attempt to answer NAME I think there is an difference in opinion if this affects the RTT estimate or not in a negative way. And thus I like to better understand if I there is any substance here or not. Likely there is not, but let continue the discussion a little bit more.
This design is very much intentional. For example, if a peer specifies a max ack delay of 10 ms but always delays ACKs 100ms, then IF one always used the peer's ackdelay without capping it at maxack_delay, it could result in repeated spurious PTOs. Re-reading the text, I do believe it says the right thing:
Ok, I can understand the intention here to say that you need to behave as promised, and to do otherwise gives a to big advantage to the misbehaving peers therefore we will include any time beyond max ACK delay in the RTT. But, that is not quite what the motivation text says. So I don't see any need for a technical change. I think it would be good to adjust the motivation so that it more correctly reflects the reasons.
SG, I added a sentence, PTAL at
Marking this "editorial" based on
Issue resolved by editorial PR.
One nit

Discussion:
by the peer that are greater than the peer's max_ack_delay are attributed to unintentional but potentially repeating delays, such as scheduler latency at the peer or loss of previous acknowledgements. <ins> Excess delays could also be due to a non-compliant receiver. </ins> Therefore, these extra delays are considered effectively part of path delay and incorporated into the RTT estimate.