Date: Wed, 04 Jan 2017 10:27:56 -0800
From: Patrick McManus <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/104/270446893@github.com>
In-Reply-To: <quicwg/base-drafts/issues/104@github.com>
References: <quicwg/base-drafts/issues/104@github.com>
Subject: Re: [quicwg/base-drafts] Priority in QUIC Transport (#104)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_586d3eacd0817_7c43fd118a65134179754";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/do81L2B2wxv--Sa15d7plSFrMfQ>
Cc: Subscribed <subscribed@noreply.github.com>
Reply-To: quic@ietf.org

----==_mimepart_586d3eacd0817_7c43fd118a65134179754
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

in general moving information down the pipeline as fast as you can without creating a HoL-Blocking problem is a good strategy. The blocking problem is the reason an H2 impl has to hold back data from TCP, and it would seem to correlate somewhat to a congestion controller's desire to not create buffering in the network (via crystal ball).

I think that argues for moving prio to the quic transport layer. mux without pri is indeed lame.. and quic wisely retransmits frames instead of packets, so prio can play a role there if prio is part of the frame otherwise this is all opaque to quic during retransmit.

-- 
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/104#issuecomment-270446893
----==_mimepart_586d3eacd0817_7c43fd118a65134179754
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>in general moving information down the pipeline as fast as you can witho=
ut creating a HoL-Blocking problem is a good strategy. The blocking problem=
 is the reason an H2 impl has to hold back data from TCP, and it would seem=
 to correlate somewhat to a congestion controller's desire to not create bu=
ffering in the network (via crystal ball).</p>
<p>I think that argues for moving prio to the quic transport layer. mux wit=
hout pri is indeed lame.. and quic wisely retransmits frames instead of pac=
kets, so prio can play a role there if prio is part of the frame otherwise =
this is all opaque to quic during retransmit.</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/104#issuecomment-270446893">view it on GitHub</a>, or <a hr=
ef=3D"https://github.com/notifications/unsubscribe-auth/AWbkqxOOhQKvosHE_M2=
yUSC3cysAGchoks5rO-SsgaJpZM4LWi4b">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq0IdkvinNyEgOt1BI=
X7lU9KR7Cs_ks5rO-SsgaJpZM4LWi4b.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/104#issuecomment-270446893"></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":"@mcmanus in #104: in general mov=
ing information down the pipeline as fast as you can without creating a HoL=
-Blocking problem is a good strategy. The blocking problem is the reason an=
 H2 impl has to hold back data from TCP, and it would seem to correlate som=
ewhat to a congestion controller's desire to not create buffering in the ne=
twork (via crystal ball).\r\n\r\nI think that argues for moving prio to the=
 quic transport layer. mux without pri is indeed lame.. and quic wisely ret=
ransmits frames instead of packets, so prio can play a role there if prio i=
s part of the frame otherwise this is all opaque to quic during retransmit.=
"}],"action":{"name":"View Issue","url":"https://github.com/quicwg/base-dra=
fts/issues/104#issuecomment-270446893"}}}</script>=

----==_mimepart_586d3eacd0817_7c43fd118a65134179754--