Re: [quicwg/base-drafts] Composability of QUIC Extensions (#3332)

[ekr <[e-mail]>]

On Fri, Jan 10, 2020 at 3:13 PM David Schinazi <[e-mail]>
wrote:

> I really don't think we should ban extensions from modifying core frames.
> I think this restricts our extensibility without providing any benefits
> that I can see.
>
> The original example is a good one: if extension A wants to modify ACK
> frames to add field ACK_FIELD_A at the end of the ACK frame and extension B
> does the same with the ACK_FIELD_B field, then we have a problem when both
> extensions are in use: we don't know how to parse ACK frames (is
> ACK_FIELD_B before or after ACK_FIELD_A?).
>
> However, saying that extensions should have their own separate frame types
> does not solve this problem. If extension A defines custom frame type ACK_A
> which contains a regular ACK plus ACK_FIELD_A, and B does the same with
> ACK_B, we end up having to send double the ACK data to get ACK_FIELD_A and
> ACK_FIELD_B across, and in my opinion that's a deal-breaker.
>
> Therefore we'll need to define how to compose extensions A and B, no
> matter what. Banning changes to existing core frames didn't solve this
> problem.
>
> If and when we do end up having this problem, we can deal with it then.
>
I agree with David. If you have extensions which are non-orthogonal, having
the wire encoding be separate isn't going to help that much.

I propose we just don't have this requirement and the first time it comes
up, we figure it out then.

-Ekr


-- 
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/3332#issuecomment-573255354