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> 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>
> > 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.
> > >
>
>