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

I think 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 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-431719835