Date: Tue, 14 Mar 2017 16:24:32 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab55302bbfe8f7b06ad57d5384901d31803ed04f1592cf0000000114e03db092a169ce0cbc0439@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/390/286593325@github.com>
In-Reply-To: <quicwg/base-drafts/issues/390@github.com>
References: <quicwg/base-drafts/issues/390@github.com>
Subject: Re: [quicwg/base-drafts] Flow/congestion control and rejected 0-RTT
 (#390)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_58c87bb0a97a0_7ede3fde590a5c2c1850ea";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/UXJny8HmzryjG4pxW0oYs-pHX-c>

----==_mimepart_58c87bb0a97a0_7ede3fde590a5c2c1850ea
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

> One important point is that even if the 0RTT packets are 'lost' and need to be retransmitted, they should not be considered lost from a congestion control perspective.

Yes, that is why I had separate points for this.  "lost" doesn't quite cut it.

> If we could say rejected 0RTT packets don't count towards flow control, I think we would no longer have to exempt stream 1 from counting towards connection level flow control, which would be nice.

Since they *can't* count, that's academic.  I'm more concerned about flow control when 0-RTT is accepted.  Connection flow control can still kick in.

There is an alternative design, which would require rolling back a change (it's one that I don't like so I am biased a little, but I really like this alternative).

We require clients to remember transport parameters.  In particular, we require that clients remember the connection-level flow control limit.  We define a new transport parameter that only applies to 0-RTT: maximum bytes.  The same limit exists in TLS, and I was going to propose that we include this anyway (I've opened #405 to do this, since I obviously neglected to do so).

If we choose to apply that limit to STREAM payloads (my preference), then we can say that this value MUST be at least X octets less than the initial connection flow control offset (Finished is usually the hash output, so I imagine that 128 octets would be plenty of slack).  Then, you always have space for at least a Finished message.  

Note: Client authentication doesn't interfere with this because it can't be used in conjunction with 0-RTT.

-- 
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/390#issuecomment-286593325
----==_mimepart_58c87bb0a97a0_7ede3fde590a5c2c1850ea
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote>
<p>One important point is that even if the 0RTT packets are 'lost' and need=
 to be retransmitted, they should not be considered lost from a congestion =
control perspective.</p>
</blockquote>
<p>Yes, that is why I had separate points for this.  "lost" doesn't quite c=
ut it.</p>
<blockquote>
<p>If we could say rejected 0RTT packets don't count towards flow control, =
I think we would no longer have to exempt stream 1 from counting towards co=
nnection level flow control, which would be nice.</p>
</blockquote>
<p>Since they <em>can't</em> count, that's academic.  I'm more concerned ab=
out flow control when 0-RTT is accepted.  Connection flow control can still=
 kick in.</p>
<p>There is an alternative design, which would require rolling back a chang=
e (it's one that I don't like so I am biased a little, but I really like th=
is alternative).</p>
<p>We require clients to remember transport parameters.  In particular, we =
require that clients remember the connection-level flow control limit.  We =
define a new transport parameter that only applies to 0-RTT: maximum bytes.=
  The same limit exists in TLS, and I was going to propose that we include =
this anyway (I've opened <a href=3D"https://github.com/quicwg/base-drafts/i=
ssues/405" class=3D"issue-link js-issue-link" data-url=3D"https://github.co=
m/quicwg/base-drafts/issues/405" data-id=3D"214235065" data-error-text=3D"F=
ailed to load issue title" data-permission-text=3D"Issue title is private">=
#405</a> to do this, since I obviously neglected to do so).</p>
<p>If we choose to apply that limit to STREAM payloads (my preference), the=
n we can say that this value MUST be at least X octets less than the initia=
l connection flow control offset (Finished is usually the hash output, so I=
 imagine that 128 octets would be plenty of slack).  Then, you always have =
space for at least a Finished message.</p>
<p>Note: Client authentication doesn't interfere with this because it can't=
 be used in conjunction with 0-RTT.</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/issues/390#issuecomment-286593325">view it on GitHub</a>, or <a hr=
ef=3D"https://github.com/notifications/unsubscribe-auth/AWbkq964jAY1Knq0Ugp=
wwEUBwDizpJl7ks5rlyGwgaJpZM4MavGm">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq6WScxQbWoGEzjiqZ=
wF2cQNkfuzQks5rlyGwgaJpZM4MavGm.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/issu=
es/390#issuecomment-286593325"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue 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":"@martinthomson in #390: \u003e O=
ne important point is that even if the 0RTT packets are 'lost' and need to =
be retransmitted, they should not be considered lost from a congestion cont=
rol perspective.\r\n\r\nYes, that is why I had separate points for this.  \=
"lost\" doesn't quite cut it.\r\n\r\n\u003e If we could say rejected 0RTT p=
ackets don't count towards flow control, I think we would no longer have to=
 exempt stream 1 from counting towards connection level flow control, which=
 would be nice.\r\n\r\nSince they *can't* count, that's academic.  I'm more=
 concerned about flow control when 0-RTT is accepted.  Connection flow cont=
rol can still kick in.\r\n\r\nThere is an alternative design, which would r=
equire rolling back a change (it's one that I don't like so I am biased a l=
ittle, but I really like this alternative).\r\n\r\nWe require clients to re=
member transport parameters.  In particular, we require that clients rememb=
er the connection-level flow control limit.  We define a new transport para=
meter that only applies to 0-RTT: maximum bytes.  The same limit exists in =
TLS, and I was going to propose that we include this anyway (I've opened #4=
05 to do this, since I obviously neglected to do so).\r\n\r\nIf we choose t=
o apply that limit to STREAM payloads (my preference), then we can say that=
 this value MUST be at least X octets less than the initial connection flow=
 control offset (Finished is usually the hash output, so I imagine that 128=
 octets would be plenty of slack).  Then, you always have space for at leas=
t a Finished message.  \r\n\r\nNote: Client authentication doesn't interfer=
e with this because it can't be used in conjunction with 0-RTT."}],"action"=
:{"name":"View Issue","url":"https://github.com/quicwg/base-drafts/issues/3=
90#issuecomment-286593325"}}}</script>=

----==_mimepart_58c87bb0a97a0_7ede3fde590a5c2c1850ea--