- From: Erik Nygren <erik@nygren.org>
- Date: Tue, 8 Jul 2014 21:11:25 -0400
- To: Roberto Peon <grmocg@gmail.com>
- Cc: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, Jeff Pinner <jpinner@twitter.com>, Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKC-DJjsVE3abALpisG_4-jGqT-tOuR6ORXf2xBW6b6tqGhg4A@mail.gmail.com>
Would getting rid of the reference set also allow us to move the static table back to a fixed position? That also seemed like it would have value for some implementations and use-cases based on the previous discussion but was problematic as long as we had the reference set, as I remember it. Erik On Tue, Jul 8, 2014 at 7:34 PM, Roberto Peon <grmocg@gmail.com> wrote: > There are two HOL blocking issues w.r.t. headers: > 1) HOL blocking because you can't send data frames while headers are > being transmitted. > 2) HOL blocking because you can't create other new streams while headers > are being transmitted. > > Removing the reference set doesn't change either of these. > > #1 occurs because of an artificial restriction added to the spec for the > sake of implementation simplicity. > We could remove tomorrow by allowing data frames to interleave with > headers/continuation. > #2 is the big(ger) issue. > > The easiest solution to #2 is to send small headers, which is what > commonly takes place today. > Assuming that large headers are being sent, however, > > Even without a reference set, anything that modifies or references state > places an ordering requirement on header data. > Getting rid of the reference set reduces HPACK code complexity for > decoders and encoders slightly, and that is about it as far as properties > of that change. > Making emission of the reference set explicit (instead implicit at the end > of the header block) helps to reduce encoder complexity somewhat, but the > opcode-frame-boundary-crossing issues still exist. > > Jeff's proposal of separating SYN_STREAM is meant to help address #2. > I don't know if that would work, however, since knowing what the stream is > about or addressed to requires the headers, which in turn means that stream > creation is always tied to headers anyway... and you end up HOL blocking on > 'em at the receiver, though not necessarily on the wire. > -=R > > > On Tue, Jul 8, 2014 at 2:28 PM, <K.Morgan@iaea.org> wrote: > >> On 08 Jul 2014, at 19:05, "jpinner@twitter.com" <jpinner@twitter.com> >> wrote: >> > >> > To be clear, the proposal is: >> > >> > 1) Remove the reference set from HPACK (use "Linear-H") >> > 2) Increase the frame size to 16-bits >> > 3) Allow interleaving of HEADERS frames >> > 4) Remove the "\0" separator hack. >> > >> > Coupling this with my earlier proposal to add a "SYN_STREAM" header >> > would also allow us to: >> > >> > 5) Remove CONTINUATION frames entirely >> > 6) Move END_* flags to the last HEADERS frame >> > 7) Flow control HEADERS frames >> > >> >> Hi Jeff- >> >> Can you please explain why the SYN_STREAM frame is necessary? It seems to >> me that just removing the reference set would get rid of the need for >> CONTINUATION frames since there would no longer be a requirement to process >> all headers together as one big "jumbo block", just a requirement to >> process frames in order. >> >> To be short, it seems to me that getting rid of the reference set also >> solves 5, 6, & 7?? >> >> -Keith >> >> This email message is intended only for the use of the named recipient. >> Information contained in this email message and its attachments may be >> privileged, confidential and protected from disclosure. If you are not the >> intended recipient, please do not read, copy, use or disclose this >> communication to others. Also please notify the sender by replying to this >> message and then delete it from your system. >> >> >
Received on Wednesday, 9 July 2014 01:11:52 UTC