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

[Kazuho Oku <[e-mail]>]

@mikkelfj 
> I (kind of) like what @kazuho wrote about blocks/boundaries within a stream in v2, but this is a large topic that digs into partial reliability. I'm not sure boundaries on their own are that useful because a flag in a stream header still require a stream frame while an application embedding its own framing can be more dense, depending on the frame size vs. packet size.

Well, it's a matter of how you encode it. We can for example define the encoding of STREAM frame as a series of blocks. That way, we can eliminate having needless metadata (i.e. stream ID, offset) for each block.

> I did make such a proposal a boundary proposal a long time ago (out of scope for v1).

Yeah. While I think that is the ideal thing to do, I do not want to revisit the discussion now. My intention is to use it as a counter-approach to express my impression that occasionally using EOS as a terminator of DATA frame is kind of a band-aid solution. Admittedly, this is a nice-looking band aid. But it is not ideal, and I'd prefer either applying it minimally or deferring it to v2 to fix the issue in the ideal way.

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