Re: Lifting HTTP/3 Features into Extensions

On 13/12/2018 06:46, Adrien de Croy wrote:
> 
> Anyone proposing moving features out to optional extensions would be 
> well advised to look at the history of IMAP, and the interop nightmare 
> that this approach causes.
> 
> I think we need to take a good long look and make things we need 
> non-optional.  If something is truly optional then you have to be 
> prepared for it to cause interop problems, and you get a chicken and egg 
> problem, where client vendors won't add support for an option unless a 
> server vendor does, and vice versa. Making a feature optional is a 
> pretty good way to consign it to oblivion..

Yes... websockets has a similar story... extensions were used as a 
somewhat desperate measure to carve off subjects that didn't seem to 
have a good way to be resolved in the standard in the short term, 
multiplexing and compression.

Multiplexing on ws never happened, and came to fruition as h2. 
Compression happened but it is literally the only extension.  Most 
implementations of ws don't implement it.

When extensions come up as a solution it's maybe better to resist the 
urge to try to keep everyone happy and instead say either this fits with 
what we want to do and we will deal with it as a first-class citizen, or 
it is outside the scope of what we are doing.

In the case of trailers, IMHO they should be banned just like chunking 
was in h2 to simplify the protocol.  If intermediaries want to pass h1 
or h2 over h3 they can take care of fixing the trailers into headers 
just like h1 over h2 has to take care of stripping the chunking.

-Andy

> ------ Original Message ------
> From: "David Schinazi" <dschinazi.ietf@gmail.com 
> <mailto:dschinazi.ietf@gmail.com>>
> To: "mbishop@evequefou.be" <mbishop@evequefou.be 
> <mailto:mbishop@evequefou.be>>
> Cc: "Ian Swett" <ianswett@google.com <mailto:ianswett@google.com>>; 
> "ianswett=40google.com@dmarc.ietf.org" 
> <ianswett=40google.com@dmarc..ietf.org 
> <mailto:ianswett=40google.com@dmarc.ietf.org>>; "fenix@fb.com" 
> <fenix@fb.com <mailto:fenix@fb.com>>; "Ryan Hamilton" <rch@google.com 
> <mailto:rch@google.com>>; "jri.ietf@gmail.com" <jri.ietf@gmail.com 
> <mailto:jri.ietf@gmail.com>>; "ietf-http-wg@w3.org" <ietf-http-wg@w3.org 
> <mailto:ietf-http-wg@w3.org>>; "Lucas Pardue" 
> <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>>; "QUIC" 
> <quic@ietf.org <mailto:quic@ietf.org>>; "Martin Thomson" 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>; 
> "kazuhooku@gmail.com" <kazuhooku@gmail.com <mailto:kazuhooku@gmail.com>>
> Sent: 13/12/2018 10:12:39 AM
> Subject: Re: Lifting HTTP/3 Features into Extensions
> 
>> I think there is value in moving some features to extensions. I don't 
>> see anything in the charter preventing us from moving specific work 
>> items to extensions, especially if we believe it'll accelerate us 
>> shipping v1, and allow experimentations that could produce a better 
>> prioritization scheme. From what I heard from people involved in the 
>> HTTP/2 standardization efforts, some things about prioritization and 
>> push could have been done differently, and most likely would have if 
>> they had been standardized as extensions. It would be great for us to 
>> gain this flexibility in HTTP/3. Moving trailers to an extension would 
>> allow us to remove the length from DATA.
>>
>> David
>>
>> On Wed, Dec 12, 2018 at 10:43 AM Mike Bishop <mbishop@evequefou.be 
>> <mailto:mbishop@evequefou.be>> wrote:
>>
>>     To preface, this is really a separate discussion, linked to this
>>     one only by what is effectively whataboutism.  We don’t have
>>     consensus to do this complicating thing that optimizes for a
>>     common case, so why did we achieve consensus to do those other
>>     complicated things that optimize for uncommon cases?  But that
>>     consensus was achieved in HTTP/2, and my personal reading of the
>>     charter leads me to believe we’re prohibited from wholesale
>>     removal of H2 features in HTTP/3; we try to keep the same general
>>     spirit unless things are fundamentally incompatible with running
>>     over QUIC.____
>>
>>     __ __
>>
>>     Moving everything post-DATA to a separate stream is a fairly
>>     dramatic change, and I’m having trouble seeing exactly how that
>>     would work.  And it suffers the same liability that it’s likely to
>>     be an under-exercised code path. ____
>>
>>     __ __
>>
>>     Priority and push were both controversial pieces of H2 for various
>>     reasons.  Unlike in HTTP/2, they are more decoupled from the
>>     stream state model in HTTP/3, and either or both could easily
>>     could become an extension.  I find the argument more persuasive
>>     for priority than for push, because one could very reasonably
>>     choose to experiment with several independent priority schemes –
>>     the pseudo-7540-style we have now, the three-bit SPDY-style
>>     priorities, a varint fixed priority, the weighted-group
>>     <https://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0396.html>,
>>     etc.____
>>
>>     __ __
>>
>>     *From:* Ian Swett <ianswett@google.com <mailto:ianswett@google.com>>
>>     *Sent:* Wednesday, December 12, 2018 9:27 AM
>>     *To:* ianswett=40google.com@dmarc.ietf.org
>>     <mailto:40google.com@dmarc.ietf.org>; Roberto Peon <fenix@fb.com
>>     <mailto:fenix@fb.com>>; Ryan Hamilton <rch@google.com
>>     <mailto:rch@google.com>>; Jana Iyengar <jri.ietf@gmail.com
>>     <mailto:jri.ietf@gmail.com>>; Mike Bishop <mbishop@evequefou.be
>>     <mailto:mbishop@evequefou.be>>; HTTP Working Group
>>     <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>; Lucas Pardue
>>     <lucaspardue.24.7@gmail.com <mailto:lucaspardue.24.7@gmail.com>>;
>>     IETF QUIC WG <quic@ietf.org <mailto:quic@ietf.org>>; Martin
>>     Thomson <martin.thomson@gmail.com
>>     <mailto:martin.thomson@gmail.com>>; Kazuho Oku
>>     <kazuhooku@gmail.com <mailto:kazuhooku@gmail.com>>
>>     *Subject:* Re: Final DATA frames____
>>
>>     __ __
>>
>>     From a technical perspective, yes.  But from a goals/process
>>     perspective, I think they related.  We've spent a lot of time on
>>     very complex work in the QUIC WG, and I realize everyone has a
>>     different perspective, but I'm confused by the amount of pushback
>>     this got relative to all the work we have done to make PUSH and
>>     something approximating(since they're actually different) H2
>>     priorities work on top of QUIC.____
>>
>>     __ __
>>
>>     If I remember correctly, your main argument against this framing
>>     change was that the existing DATA frame with a length becomes
>>     largely useless and might be under-exercised.  That makes me feel
>>     like we've over-optimized for the complex special cases and made a
>>     design error or two at least one step prior to this proposal.____
>>
>>     __ __
>>
>>     To make a specific and relevant suggestion, maybe DATA should
>>     never have a length and if we want features that most requests
>>     don't use(trailers/PUSH_PROMISE/etc) we should put them on a
>>     separate unidirectional stream?____
>>
>>     __ __
>>
>>     __ __
>>
>>     __ __
>>
>>     On Wed, Dec 12, 2018 at 12:02 PM Dmitri Tikhonov
>>     <dtikhonov@litespeedtech.com <mailto:dtikhonov@litespeedtech.com>>
>>     wrote:____
>>
>>         But you would agree that these are completely different
>>         discussions?
>>
>>         One is whether to modify HTTP/3 framing mechanism.  The other is
>>         changing HTTP/3 feature set.
>>
>>         My point is that it is unjustified to to say that since we have
>>         decided not to change the framing mechanism we should consider
>>         dropping prioritization and push promises.
>>
>>         On Wed, Dec 12, 2018 at 11:38:09AM -0500, Ian Swett wrote:
>>         > I don't want to derail this too much(probably too late for
>>         that), and no
>>         > one has a PR anywhere close to landing, but I do think we
>>         should start
>>         > thinking of these as potential extensions.  I disagree that
>>         they're
>>         > HTTP/2's primary features, both due to lack of use and lack
>>         of measurable
>>         > benefits years after standardization.  Push might actually
>>         benefit from
>>         > being an extension, because then potential improvements(ie:
>>         cache-digest)
>>         > could be integrated into the extension more quickly.
>>         >
>>         > On the other hand, QPACK is relatively complex but we have
>>         clearer
>>         > demonstrations of it's benefit.
>>         >
>>         > On Wed, Dec 12, 2018 at 9:00 AM Dmitri Tikhonov
>>         <dtikhonov@litespeedtech.com <mailto:dtikhonov@litespeedtech.com>>
>>         > wrote:
>>         >
>>         > > On Tue, Dec 11, 2018 at 09:02:01PM -0500, Ian Swett wrote:
>>         > > > TLDR: If the focus is on shipping v1 and making sure we
>>         don't introduce
>>         > > > premature optimizations into HTTP/3, I thInk we should
>>         seriously consider
>>         > > > moving PUSH and the existing priorities to an extension.
>>         > >
>>         > > The EOS DATA frame and HTTP prioritization and push
>>         promises are not
>>         > > equivalent.  One is simply fiddling with the way data is
>>         framed and
>>         > > is not visible to the application.  The others are
>>         HTTP/2's primary
>>         > > features.
>>         > >
>>         > >   - Dmitri.
>>         > >____
>>

Received on Thursday, 13 December 2018 00:14:20 UTC