Subject: [quicwg/base-drafts] MinRTT for the congestion control context (#2919)

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 12:43:58 -0700

Also explains what happens to MinRTT if the path RTT changes.

Fixes #2908
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2919

-- Commit Summary --

  * MinRTT for the congestion control context

-- File Changes --

    M draft-ietf-quic-recovery.md (23)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2919.patch
https://github.com/quicwg/base-drafts/pull/2919.diff

-- 
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/pull/2919

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 12:45:25 -0700

@ianswett pushed 1 commit.

eead856d0a445f35be1f55f0823c759a53ab9eab  Fix a long line

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2919/files/d2eae3ff88e64a67ad605f58a6f981b14fd26739..eead856d0a445f35be1f55f0823c759a53ab9eab

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 21 Jul 2019 13:07:29 -0700

janaiyengar commented on this pull request.

>  following three values: the minimum value observed over the lifetime of the
-connection (min_rtt), an exponentially-weighted moving average (smoothed_rtt),
-and the variance in the observed RTT samples (rttvar).
+congestion control context (min_rtt), an exponentially-weighted moving average

```suggestion
RTT estimator's context (min_rtt), an exponentially-weighted moving average
```

-- 
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/pull/2919#pullrequestreview-264552441

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 21 Jul 2019 13:17:37 -0700

> @@ -371,16 +371,23 @@ retain sufficient history is an open research question.
 
 ## Estimating min_rtt {#min-rtt}
 
-min_rtt is the minimum RTT observed over the lifetime of the connection.
-min_rtt is set to the latest_rtt on the first sample in a connection, and to the
-lesser of min_rtt and latest_rtt on subsequent samples.
+min_rtt is the minimum RTT observed for a given congestion control context.

min_rtt is only used for loss recovery in this doc. I think it's more appropriate to say RTT estimator context in general. 

> @@ -371,16 +371,23 @@ retain sufficient history is an open research question.
 
 ## Estimating min_rtt {#min-rtt}
 
-min_rtt is the minimum RTT observed over the lifetime of the connection.
-min_rtt is set to the latest_rtt on the first sample in a connection, and to the
-lesser of min_rtt and latest_rtt on subsequent samples.
+min_rtt is the minimum RTT observed for a given congestion control context.
+min_rtt is set to the latest_rtt on the first RTT sample, and to the lesser
+of min_rtt and latest_rtt on subsequent samples.  min_rtt is used to reject
+implausible RTT samples, but is not used directly in congestion control or

I would drop the rest of the text after "samples" and perhaps add "which would otherwise cause the smoothed_rtt estimate to be incorrectly low.". I understand what you're trying to say, but I think saying that it is not used directly in loss recovery makes it a bit confusing I think. It is used, and I think people will have different reads on what's indirect and what's 

 An endpoint uses only locally observed times in computing the min_rtt and does
 not adjust for host delays reported by the peer ({{host-delay}}).  Doing so
 allows the endpoint to set a lower bound for the smoothed_rtt based entirely on
 what it observes (see {{smoothed-rtt}}), and limits potential underestimation
 due to erroneously-reported delays by the peer.
 
+The RTT for the path may change over time.  If the real path RTT decreases,

```suggestion
The RTT for a path may change over time.  If a path's actual RTT decreases,
```

 An endpoint uses only locally observed times in computing the min_rtt and does
 not adjust for host delays reported by the peer ({{host-delay}}).  Doing so
 allows the endpoint to set a lower bound for the smoothed_rtt based entirely on
 what it observes (see {{smoothed-rtt}}), and limits potential underestimation
 due to erroneously-reported delays by the peer.
 
+The RTT for the path may change over time.  If the real path RTT decreases,
+it should be observed quickly.  If the real path RTT increases, it will not

```suggestion
the min_rtt will adapt immediately on the first low sample.  If the path's actual RTT increases,
```

 An endpoint uses only locally observed times in computing the min_rtt and does
 not adjust for host delays reported by the peer ({{host-delay}}).  Doing so
 allows the endpoint to set a lower bound for the smoothed_rtt based entirely on
 what it observes (see {{smoothed-rtt}}), and limits potential underestimation
 due to erroneously-reported delays by the peer.
 
+The RTT for the path may change over time.  If the real path RTT decreases,
+it should be observed quickly.  If the real path RTT increases, it will not
+be observed, but the impact is limited to allowing some RTT samples that are

```suggestion
the min_rtt will not adapt to it, potentially causing future RTT samples that are
```

> @@ -410,11 +417,11 @@ endpoint:
   min_rtt.  This limits the underestimation that a misreporting peer can cause
   to the smoothed_rtt.
 
-On the first RTT sample in a connection, the smoothed_rtt is set to the
-latest_rtt.
+On the first RTT sample in a congestion control context, the smoothed_rtt is

RTT context

 smoothed_rtt and rttvar are computed as follows, similar to {{?RFC6298}}.  On
-the first RTT sample in a connection:
+the first RTT sample in a congestion control context:

RTT context

-- 
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/pull/2919#pullrequestreview-264552498

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:44:35 -0700

ianswett commented on this pull request.

We never define this, but isn't the RTT estimator a subset of the congestion control context?  Also, we only use RTT estimator once in this document at the moment.

Possibly I should use path for all of these now, against @erickinnear suggestion?  Also, path is much shorter than "congestion control context"

-- 
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/pull/2919#discussion_r305637430

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:45:20 -0700

32ee7e524d6582a317cb4ec3ffbd23263a6040d0  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2919/files/eead856d0a445f35be1f55f0823c759a53ab9eab..32ee7e524d6582a317cb4ec3ffbd23263a6040d0

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:45:39 -0700

path?

-- 
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/pull/2919#discussion_r305637470

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:45:45 -0700

path?

-- 
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/pull/2919#discussion_r305637474

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:46:07 -0700

f0169fe1e0568effdc7307ea1613750e70b06056  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2919/files/32ee7e524d6582a317cb4ec3ffbd23263a6040d0..f0169fe1e0568effdc7307ea1613750e70b06056

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:46:31 -0700

9c1e11a0221952729437f0692ca8a079b4102523  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2919/files/f0169fe1e0568effdc7307ea1613750e70b06056..9c1e11a0221952729437f0692ca8a079b4102523

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 14:47:33 -0700

c1604ae7dcaed0cd4cf624c946e5470bb887efa4  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2919/files/9c1e11a0221952729437f0692ca8a079b4102523..c1604ae7dcaed0cd4cf624c946e5470bb887efa4

---

From: Eric Kinnear <[email-masked]>
Date: Sun, 21 Jul 2019 15:22:42 -0700

erickinnear commented on this pull request.

Elsewhere don’t we discuss resetting a congestion control context? It seems like that often lines up with a path, but they don’t have to be the same thing. It seems like you’re saying that RTT isn’t part of congestion control (which sounds totally valid but we then need some better way to word 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/pull/2919#discussion_r305638679

---

From: Martin Thomson <[email-masked]>
Date: Mon, 22 Jul 2019 05:35:52 -0700

martinthomson commented on this pull request.

 

When you say "congestion control context", why not "path"?

-- 
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/pull/2919#discussion_r305820856

---

From: ianswett <[email-masked]>
Date: Mon, 22 Jul 2019 07:03:32 -0700

Good question, I'll talk with Eric and Jana in person about this one and we can figure out some consistent terminology.

-- 
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/pull/2919#discussion_r305861824