Re: [quicwg/base-drafts] Use a "stream" for transmitting CIDs (#1826)

[Kazuho Oku <[e-mail]>]

@nibanks 
> I still feel that making them a stream is more overhead than necessary. For instance, if you sent three new CIDs to the peer and the first is lost, if you have a stream design, the second two stay around longer than necessary on the sender side.

It is true that head-of-line blocking exists. But IMO it is not an issue latency-wise (because there is no need to race for 1-RTT for delivering / retiring CIDs) nor memory-wise (because CIDs are so small compared to stream buffers and because there would only be few CIDs inflight.

> Overall, I'm still not sure of the problem that currently exists that this is the solution to. What doesn't work with the current model that would require this design to fix? I feel like we're at a phase where we should start taking changes required to fix a particular problem, not changes that (some believe) make for a cleaner design.

FWIW, my view is that the proposal retains the new model (i.e. retirement of CIDs always transmitted as an explicit signal), at the same time changing the transmission framework of the CIDs to a mechanism that have proven record (rather than introducing a framework specific to the purpose).

As I have stated earlier, it is beneficial to use a proven method because we are at a later moment like this, instead of trying to fix all the design issues of a framework specific to transmitting CIDs that we haven't seen any interop.

-- 
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/1826#issuecomment-426412476