Re: [quicwg/base-drafts] DATA frame encoding is inefficient for long dynamically generated bodies (#1885)

[Kazuho Oku <[e-mail]>]

@LPardue 
> There is some industry attention being paid to chunking end-to-end through the delivery chain.

I understand the same way.

> Perhaps there's scope for an extension to HQ and/or H2 that can explicitly declare no trailers on a stream, wresting performance on the endcode or pass through cases.

I am not sure if I like the complexity, partly because the small performance gain we will see (see @dtikhonov' comment at https://github.com/quicwg/base-drafts/issues/1885#issuecomment-431348155), and also because it could be hard to use; it is often the case that a proxy cannot guess at the time of connection establishment to which origin server it would be connecting (consider the use of secondary server certificates).

I think my preference might goes to fixing the issue in QUIC v2. For example, we could move the chunking layer into the transport. In addition to EOS, we could have a END_OF_BLOCK flag associated to a STREAM frame that indicates the end of each block within a STREAM.

Assuming that many of the application protocols will transfer size-delimited blocks (e.g. HQ frames), it would make sense to support the concept in transport.

Having it expressed as a flag of a STREAMS frame (by burning the frame type octet) will give us simplicity _and_ efficiency in terms of bandwidth, because we can totally omit the Length field of the HQ frames.

-- 
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/1885#issuecomment-431719488