Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD53120193 for ; Sun, 21 Jul 2019 13:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX59WLAIf8tA for ; Sun, 21 Jul 2019 13:17:38 -0700 (PDT) Received: from out-9.smtp.github.com (out-9.smtp.github.com [192.30.254.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F34A1200B9 for ; Sun, 21 Jul 2019 13:17:38 -0700 (PDT) Date: Sun, 21 Jul 2019 13:17:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563740257; bh=q+EhtQt5psQRey4IbRS3MPHVC2Ywxv7G7Z69ROW6Q+g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xuxRUrpRFm64MlP60DpQzXzVbfA81faVdzaq2h6WKenkvlq5M8KQ4v3LQVXWpm1jY 49repTZlu+tAuumK3ETQnf5/cLUQrg+BQ9geiImW9prmpUOjk3uFB7GwqtvKtxy6gz Luk7Qp7567ONyKHKvwh+0Yzc2bh2rBPyXSWowdew= From: Jana Iyengar Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] MinRTT for the congestion control context (#2919) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5d34c861726f7_3aa53fc570ccd95c89813e"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: janaiyengar X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 20:17:48 -0000 ----==_mimepart_5d34c861726f7_3aa53fc570ccd95c89813e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit janaiyengar commented on this pull request. > @@ -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 ----==_mimepart_5d34c861726f7_3aa53fc570ccd95c89813e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@janaiyengar commented on this pull request.

=0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

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

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

=0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

=0D 
> @@ -371,16 +371,23 @@ retain sufficient hi=
story is an open research question.=0D
 =0D
 ## Estimating min_rtt {#min-rtt}=0D
 =0D
-min_rtt is the minimum RTT observed over the lifetime of the connection.=
=0D
-min_rtt is set to the latest_rtt on the first sample in a connection, an=
d to the=0D
-lesser of min_rtt and latest_rtt on subsequent samples.=0D
+min_rtt is the minimum RTT observed for a given congestion control conte=
xt.=0D
+min_rtt is set to the latest_rtt on the first RTT sample, and to the les=
ser=0D
+of min_rtt and latest_rtt on subsequent samples.  min_rtt is used to rej=
ect=0D
+implausible RTT samples, but is not used directly in congestion control =
or=0D
=0D

I would drop the rest of the text after "samples" and perhaps add "whi= ch 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 i= s used, and I think people will have different reads on what's indirect a= nd what's

=0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

=0D 
>  =0D
 An endpoint uses only locally observed times in computing the min_rtt an=
d does=0D
 not adjust for host delays reported by the peer ({{host-delay}}).  Doing=
 so=0D
 allows the endpoint to set a lower bound for the smoothed_rtt based enti=
rely on=0D
 what it observes (see {{smoothed-rtt}}), and limits potential underestim=
ation=0D
 due to erroneously-reported delays by the peer.=0D
 =0D
+The RTT for the path may change over time.  If the real path RTT decreas=
es,=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-The RTT for the path may change over time.  I=
f the real path RTT decreases,=0D
+The RTT for a path may change over time.  If a path's actual RTT decreas=
es,=0D
=0D =0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

=0D 
>  =0D
 An endpoint uses only locally observed times in computing the min_rtt an=
d does=0D
 not adjust for host delays reported by the peer ({{host-delay}}).  Doing=
 so=0D
 allows the endpoint to set a lower bound for the smoothed_rtt based enti=
rely on=0D
 what it observes (see {{smoothed-rtt}}), and limits potential underestim=
ation=0D
 due to erroneously-reported delays by the peer.=0D
 =0D
+The RTT for the path may change over time.  If the real path RTT decreas=
es,=0D
+it should be observed quickly.  If the real path RTT increases, it will =
not=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-it should be observed quickly.  If the real p=
ath RTT increases, it will not=0D
+the min_rtt will adapt immediately on the first low sample.  If the path=
's actual RTT increases,=0D
=0D =0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

=0D 
>  =0D
 An endpoint uses only locally observed times in computing the min_rtt an=
d does=0D
 not adjust for host delays reported by the peer ({{host-delay}}).  Doing=
 so=0D
 allows the endpoint to set a lower bound for the smoothed_rtt based enti=
rely on=0D
 what it observes (see {{smoothed-rtt}}), and limits potential underestim=
ation=0D
 due to erroneously-reported delays by the peer.=0D
 =0D
+The RTT for the path may change over time.  If the real path RTT decreas=
es,=0D
+it should be observed quickly.  If the real path RTT increases, it will =
not=0D
+be observed, but the impact is limited to allowing some RTT samples that=
 are=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-be observed, but the impact is limited to all=
owing some RTT samples that are=0D
+the min_rtt will not adapt to it, potentially causing future RTT samples=
 that are=0D
=0D =0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

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

-latest_rtt.=0D
+On the first RTT sample in a congestion control context, the smoothed_rt=
t is=0D
=0D

RTT context

=0D =0D
=0D =0D

In draft-ietf-quic-recovery.md:

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

RTT context

=0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the th= read.3D""=

=0D = ----==_mimepart_5d34c861726f7_3aa53fc570ccd95c89813e--