Date: Mon, 20 Mar 2017 02:13:35 -0700
From: Brian Trammell <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab920721dabac15d7f48f22e99b4967b07d5fc8a5992cf0000000114e75f3f92a169ce0cbd1e83@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/391/c287707095@github.com>
In-Reply-To: <quicwg/base-drafts/pull/391@github.com>
References: <quicwg/base-drafts/pull/391@github.com>
Subject: Re: [quicwg/base-drafts] Packet number echo with variable-length
 numbering (#391)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_58cf9d3fdb8d1_18e93ff371e79c2c483d9";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/G4xgaOyAgJs4VfJL457bAQl7dDI>

----==_mimepart_58cf9d3fdb8d1_18e93ff371e79c2c483d9
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

> I think it's ok to provide an RTT measurement less frequently when little data is flowing

The issue here is that each direction isn't providing an RTT measurement; it's providing a measurement only for the component of the RTT between the observation point and one endpoint. Referring to the illustration, an observation point close to the receiver in an asymmetric flow gets the RTT component toward the receiver far more often than the RTT component toward the sender. 

> The removal of STOP_WAITING and acking acks results in sending a retransmittable frame with an ack approximately once per RTT. So both directions should get an RTT estimate approximately once per RTT.

Ah, right. Sorry, still thinking in TCP terms. Okay, so Option 2 echoes on (practically) a superset of Option 1. 

FWIW I continue to share your apprehension about making this non-optional. I like the idea of allowing application/user veto, which is only possible when the packet number echo is redundant with the ACK frames.

-- 
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/391#issuecomment-287707095
----==_mimepart_58cf9d3fdb8d1_18e93ff371e79c2c483d9
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote>
<p>I think it's ok to provide an RTT measurement less frequently when littl=
e data is flowing</p>
</blockquote>
<p>The issue here is that each direction isn't providing an RTT measurement=
; it's providing a measurement only for the component of the RTT between th=
e observation point and one endpoint. Referring to the illustration, an obs=
ervation point close to the receiver in an asymmetric flow gets the RTT com=
ponent toward the receiver far more often than the RTT component toward the=
 sender.</p>
<blockquote>
<p>The removal of STOP_WAITING and acking acks results in sending a retrans=
mittable frame with an ack approximately once per RTT. So both directions s=
hould get an RTT estimate approximately once per RTT.</p>
</blockquote>
<p>Ah, right. Sorry, still thinking in TCP terms. Okay, so Option 2 echoes =
on (practically) a superset of Option 1.</p>
<p>FWIW I continue to share your apprehension about making this non-optiona=
l. I like the idea of allowing application/user veto, which is only possibl=
e when the packet number echo is redundant with the ACK frames.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/pull/391#issuecomment-287707095">view it on GitHub</a>, or <a href=
=3D"https://github.com/notifications/unsubscribe-auth/AWbkq9ngASOxOQKpoex1U=
5GCeAsDsNjBks5rnkM_gaJpZM4MbDSe">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq2mfnGcsbmib2uwJ8=
OsJOvig4F84ks5rnkM_gaJpZM4MbDSe.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/pull=
/391#issuecomment-287707095"></link>
  <meta itemprop=3D"name" content=3D"View Pull Request"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Pull Request on GitHub"=
></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name=
":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates=
":{"snippets":[{"icon":"PERSON","message":"@britram in #391: \u003e I think=
 it's ok to provide an RTT measurement less frequently when little data is =
flowing\r\n\r\nThe issue here is that each direction isn't providing an RTT=
 measurement; it's providing a measurement only for the component of the RT=
T between the observation point and one endpoint. Referring to the illustra=
tion, an observation point close to the receiver in an asymmetric flow gets=
 the RTT component toward the receiver far more often than the RTT componen=
t toward the sender. \r\n\r\n\u003e The removal of STOP_WAITING and acking =
acks results in sending a retransmittable frame with an ack approximately o=
nce per RTT. So both directions should get an RTT estimate approximately on=
ce per RTT.\r\n\r\nAh, right. Sorry, still thinking in TCP terms. Okay, so =
Option 2 echoes on (practically) a superset of Option 1. \r\n\r\nFWIW I con=
tinue to share your apprehension about making this non-optional. I like the=
 idea of allowing application/user veto, which is only possible when the pa=
cket number echo is redundant with the ACK frames."}],"action":{"name":"Vie=
w Pull Request","url":"https://github.com/quicwg/base-drafts/pull/391#issue=
comment-287707095"}}}</script>=

----==_mimepart_58cf9d3fdb8d1_18e93ff371e79c2c483d9--