Date: Mon, 26 Nov 2018 19:49:53 +0000 (UTC)
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abfce0d1d717875febd322379e9f452bf85002aba992cf000000011814106192a169ce16d8e664@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2038/c441774031@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2038@github.com>
References: <quicwg/base-drafts/pull/2038@github.com>
Subject: Re: [quicwg/base-drafts] Default settings in HTTP (#2038)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5bfc4e61a6ba9_2a863f97d62d45bc4821d";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/YGcx5SiBh02ZZF1eW9CN5F8GuVs>

----==_mimepart_5bfc4e61a6ba9_2a863f97d62d45bc4821d
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That's a great write up but it's higher level than I was thinking.

If (and it's a big if) implementations decided it was more efficient to run
H3 on defaults without exchange of SETTINGS, we lose an effective
mechanism. This was part of the reason behind adding greasing. In practice,
I don't think this concern would play out but I wanted to identify it
before the change landed

On Mon, 26 Nov 2018, 19:33 Mike Bishop <notifications@github.com wrote:

> @LPardue <https://github.com/LPardue>, I think the key point here is in
> the text added to the extensions section: "SETTINGS does not provide a
> mechanism to identify when the choice takes effect."
>
> There are really three types of extensions:
>
>    - *Advisory, purely-optional frames / streams:* Send speculatively; if
>    the peer doesn't understand, they'll ignore them. Once you see SETTING=
S, if
>    it's not supported, you can stop sending to save bytes.
>    - *Non-optional semantic-changing frames / streams:* Send only once
>    you've seen SETTINGS, but okay to use as soon as you see SETTINGS -- y=
ou
>    know the peer will handle them on receipt. Need to be willing to handle
>    "surprise" arrival of these frames / streams before SETTINGS, unless
>    they're frames on control streams.
>    - *Breaking changes to interpretation of existing frames/streams:*
>    Here's the sticky one. There's no coordination point to know when the
>    change to existing elements takes effect, so the peer could interpret =
what
>    you send under the old or new scheme unless the extension itself provi=
des a
>    way to identify this.
>
> I think this really only harms the last category, and the easiest solution
> seems to be jumping into the previous category for most extensions I can
> envision. For example, redefining DATA to be a reference to a
> unidirectional stream instead of carrying payload would fall in the third
> bucket and be hard. But if you instead defined a new EXTERNAL_DATA frame,
> you've moved into the second bucket.
>
> =E2=80=94
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/2038#issuecomment-441767889>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGRFtbwaELdpzLfcYyLWHz=
4_Ycq1k86Fks5uzEIMgaJpZM4YuNMm>
> .
>


--=20
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/2038#issuecomment-441774031=

----==_mimepart_5bfc4e61a6ba9_2a863f97d62d45bc4821d
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

That&#39;s a great write up but it&#39;s higher level than I was thinking.<=
br>
<br>
If (and it&#39;s a big if) implementations decided it was more efficient to=
 run<br>
H3 on defaults without exchange of SETTINGS, we lose an effective<br>
mechanism. This was part of the reason behind adding greasing. In practice,=
<br>
I don&#39;t think this concern would play out but I wanted to identify it<b=
r>
before the change landed<br>
<br>
On Mon, 26 Nov 2018, 19:33 Mike Bishop &lt;notifications@github.com wrote:<=
br>
<br>
&gt; @LPardue &lt;https://github.com/LPardue&gt;, I think the key point her=
e is in<br>
&gt; the text added to the extensions section: &quot;SETTINGS does not prov=
ide a<br>
&gt; mechanism to identify when the choice takes effect.&quot;<br>
&gt;<br>
&gt; There are really three types of extensions:<br>
&gt;<br>
&gt;    - *Advisory, purely-optional frames / streams:* Send speculatively;=
 if<br>
&gt;    the peer doesn&#39;t understand, they&#39;ll ignore them. Once you =
see SETTINGS, if<br>
&gt;    it&#39;s not supported, you can stop sending to save bytes.<br>
&gt;    - *Non-optional semantic-changing frames / streams:* Send only once=
<br>
&gt;    you&#39;ve seen SETTINGS, but okay to use as soon as you see SETTIN=
GS -- you<br>
&gt;    know the peer will handle them on receipt. Need to be willing to ha=
ndle<br>
&gt;    &quot;surprise&quot; arrival of these frames / streams before SETTI=
NGS, unless<br>
&gt;    they&#39;re frames on control streams.<br>
&gt;    - *Breaking changes to interpretation of existing frames/streams:*<=
br>
&gt;    Here&#39;s the sticky one. There&#39;s no coordination point to kno=
w when the<br>
&gt;    change to existing elements takes effect, so the peer could interpr=
et what<br>
&gt;    you send under the old or new scheme unless the extension itself pr=
ovides a<br>
&gt;    way to identify this.<br>
&gt;<br>
&gt; I think this really only harms the last category, and the easiest solu=
tion<br>
&gt; seems to be jumping into the previous category for most extensions I c=
an<br>
&gt; envision. For example, redefining DATA to be a reference to a<br>
&gt; unidirectional stream instead of carrying payload would fall in the th=
ird<br>
&gt; bucket and be hard. But if you instead defined a new EXTERNAL_DATA fra=
me,<br>
&gt; you&#39;ve moved into the second bucket.<br>
&gt;<br>
&gt; =E2=80=94<br>
&gt; You are receiving this because you were mentioned.<br>
&gt; Reply to this email directly, view it on GitHub<br>
&gt; &lt;https://github.com/quicwg/base-drafts/pull/2038#issuecomment-44176=
7889&gt;,<br>
&gt; or mute the thread<br>
&gt; &lt;https://github.com/notifications/unsubscribe-auth/AGRFtbwaELdpzLfc=
YyLWHz4_Ycq1k86Fks5uzEIMgaJpZM4YuNMm&gt;<br>
&gt; .<br>
&gt;<br>


<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/2038#issuecomment-441774031">view it on GitHub</a>, or <a hre=
f=3D"https://github.com/notifications/unsubscribe-auth/AWbkq4Okmsqw1VV4v1vP=
0bOjQjmJaRcMks5uzEXhgaJpZM4YuNMm">mute the thread</a>.<img src=3D"https://g=
ithub.com/notifications/beacon/AWbkqxe-5lKAEuB0j6gqAVnU0D5sO88Eks5uzEXhgaJp=
ZM4YuNMm.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<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://asse=
ts-cdn.github.com/images/email/message_cards/header.png","avatar_image_url"=
:"https://assets-cdn.github.com/images/email/message_cards/avatar.png","act=
ion":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"=
}},"updates":{"snippets":[{"icon":"PERSON","message":"@LPardue in #2038: Th=
at's a great write up but it's higher level than I was thinking.\n\nIf (and=
 it's a big if) implementations decided it was more efficient to run\nH3 on=
 defaults without exchange of SETTINGS, we lose an effective\nmechanism. Th=
is was part of the reason behind adding greasing. In practice,\nI don't thi=
nk this concern would play out but I wanted to identify it\nbefore the chan=
ge landed\n\nOn Mon, 26 Nov 2018, 19:33 Mike Bishop \u003cnotifications@git=
hub.com wrote:\n\n\u003e @LPardue \u003chttps://github.com/LPardue\u003e, I=
 think the key point here is in\n\u003e the text added to the extensions se=
ction: \"SETTINGS does not provide a\n\u003e mechanism to identify when the=
 choice takes effect.\"\n\u003e\n\u003e There are really three types of ext=
ensions:\n\u003e\n\u003e    - *Advisory, purely-optional frames / streams:*=
 Send speculatively; if\n\u003e    the peer doesn't understand, they'll ign=
ore them. Once you see SETTINGS, if\n\u003e    it's not supported, you can =
stop sending to save bytes.\n\u003e    - *Non-optional semantic-changing fr=
ames / streams:* Send only once\n\u003e    you've seen SETTINGS, but okay t=
o use as soon as you see SETTINGS -- you\n\u003e    know the peer will hand=
le them on receipt. Need to be willing to handle\n\u003e    \"surprise\" ar=
rival of these frames / streams before SETTINGS, unless\n\u003e    they're =
frames on control streams.\n\u003e    - *Breaking changes to interpretation=
 of existing frames/streams:*\n\u003e    Here's the sticky one. There's no =
coordination point to know when the\n\u003e    change to existing elements =
takes effect, so the peer could interpret what\n\u003e    you send under th=
e old or new scheme unless the extension itself provides a\n\u003e    way t=
o identify this.\n\u003e\n\u003e I think this really only harms the last ca=
tegory, and the easiest solution\n\u003e seems to be jumping into the previ=
ous category for most extensions I can\n\u003e envision. For example, redef=
ining DATA to be a reference to a\n\u003e unidirectional stream instead of =
carrying payload would fall in the third\n\u003e bucket and be hard. But if=
 you instead defined a new EXTERNAL_DATA frame,\n\u003e you've moved into t=
he second bucket.\n\u003e\n\u003e =E2=80=94\n\u003e You are receiving this =
because you were mentioned.\n\u003e Reply to this email directly, view it o=
n GitHub\n\u003e \u003chttps://github.com/quicwg/base-drafts/pull/2038#issu=
ecomment-441767889\u003e,\n\u003e or mute the thread\n\u003e \u003chttps://=
github.com/notifications/unsubscribe-auth/AGRFtbwaELdpzLfcYyLWHz4_Ycq1k86Fk=
s5uzEIMgaJpZM4YuNMm\u003e\n\u003e .\n\u003e\n"}],"action":{"name":"View Pul=
l Request","url":"https://github.com/quicwg/base-drafts/pull/2038#issuecomm=
ent-441774031"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2038#issuecomment-441=
774031",
"url": "https://github.com/quicwg/base-drafts/pull/2038#issuecomment-441774=
031",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [quicwg/base-drafts] Default settings in HTTP (#2038)",
"sections": [
{
"text": "",
"activityTitle": "**Lucas Pardue**",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/=
avatar.png",
"activitySubtitle": "@LPardue",
"facts": [

]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"q=
uicwg/base-drafts\",\n\"issueId\": 2038,\n\"IssueComment\": \"{{IssueCommen=
t.value}}\"\n}"
}
]
},
{
"name": "Close pull request",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"PullRequestClose\",\n\"repositoryFullName\":=
 \"quicwg/base-drafts\",\n\"pullRequestId\": 2038\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/quicwg/base-drafts/pull/2038#issuecomment-441774=
031"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 414765862=
\n}"
}
],
"themeColor": "26292E"
}
]</script>=

----==_mimepart_5bfc4e61a6ba9_2a863f97d62d45bc4821d--