Subject: [quicwg/base-drafts] recovery-31: Motivation for max_ack_delay statement (#4191)

From: Magnus Westerlund <[email-masked]>
Date: Mon, 12 Oct 2020 07:33:02 -0700

In Section 5.3:

	After the handshake is confirmed, any acknowledgement delays reported 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. Therefore, these extra delays are considered effectively part of path delay and incorporated into the RTT estimate.
	
I don't understand the motivation behind this statement. Assuming that the peer is measuring their actual ack_delay, i.e. it has a sample for arrival_time[psn_highest_acked] and then when creating the ack and calculating the ack_delay it will do time(now) - arrival_time[psn_highest_acked] and that is then larger than max_ack_delay. 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 max_ack_delay. Thus, by capping the use of ack_delay to max_ack_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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191

---

From: ianswett <[email-masked]>
Date: Mon, 12 Oct 2020 08:48:24 -0700

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 @janaiyengar might have a suggestion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-707199907

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Oct 2020 12:49:57 -0700

@gloinul : 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-707313397

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Oct 2020 04:22:56 -0700

@gloinul do these explanation address your issue? Or are text changes required?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709215351

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 05:46:32 -0700

@janaiyengar 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 @larseggert: 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. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709296501

---

From: ianswett <[email-masked]>
Date: Thu, 15 Oct 2020 06:08:17 -0700

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 ack_delay without capping it at max_ack_delay, it could result in repeated spurious PTOs.

Re-reading the text, I do believe it says the right thing:
Therefore, these extra delays are considered **effectively** part of path delay

This recognizes it's not really part of the path, but we're treating it like that.  TCP always treats ack delay as part of the path  delay via SRTT and RTTVar, so this is in keeping with that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709312672

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 07:00:11 -0700

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709345031

---

From: ianswett <[email-masked]>
Date: Thu, 15 Oct 2020 07:06:26 -0700

SG, I added a sentence, PTAL at #4218

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709349342

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Oct 2020 07:20:20 -0700

Marking this "editorial" based on #4218

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709358353

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 09:04:15 -0700

Issue resolved by editorial PR. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#issuecomment-709426974

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 15 Oct 2020 14:01:42 -0700

Closed #4191 via #4218.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4191#event-3883555476