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

Actually, my preference might go to fixing the issue in QUIC v2. For example, we could move the chunking layer into the transport by adding a END_OF_BLOCK flag to a STREAM frame for indicating 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 makes 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 eliminate 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-431720220