Re: [quicwg/base-drafts] Length-prefixes and flow control (#1432)

[Martin Thomson <[e-mail]>]

Yeah, @krasic has it right.  The entire point of this thing is to apply back pressure - if you can't read, ensure that you don't get more of stuff you can't read that consumes more of the memory you don't have.

On the other hand, it is reasonable to say that applications (and application protocols) can't rely on QUIC providing them with any concrete amount of storage.   But we can't force people to read or we undermine the entire purpose of providing flow control.  (Here I'm assuming that reading releases flow control, but the key point is that you only release flow control once you are done with the octets, and for many of these cases, the point is that you can't be done with the octets until some external condition is met, or all the octets are in, or something like that.)

I don't think that this is something we have to provide a concrete solution for.  Flow control is fundamentally hard because it is about managing access to a finite resource and contention can occur, sometimes in sub-optimal ways.  What we can do is signpost the obvious pitfalls.  Like the case where you have 10 octets of connection flow control, 10 streams and 1 octet arrives for every stream, but you need to have >1 to make progress.

Using `peek()` is just an example, and not a necessary one.  The problem is that we're creating ways for an application to learn whether it wants to read octets before it reads them.  A length-prefixed encoding does that inherently, but it's just an example of a general class of things that a reader might use to decide to defer consumption of data.  That length-prefixes are also a great way to optimize processing of data means that we won't ever avoid using them, and nor can we avoid cases where atomic units take more than one octet to express.

If I get @dtikhonov's point, it seems like a suggestion that we might avoid a length-prefix, but I think that only makes reading harder, and doesn't avoid other styles of atomic processing over multi-octet fields.  It probably drives implementation complexity up, and it (unfortunately) uses a lot more bytes than a length prefix in many cases.

-- 
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/1432#issuecomment-396429043