Hiya, On Wed, Sep 30, 2020 at 5:13 PM Ian Swett <ianswett= [email protected]> wrote:
> > The existing draft(draft-deconinck-quic-multipath-05 > <https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) adds > ADD_ADDRESS/REMOVE_ADDRESS frames and modifies the ACK, NEW_CONNECTION_ID, > and RETIRE_CONNECTION_ID frames. It also adds what appears to be a > debugging frame(UNIFLOWS) and a single transport parameter to indicate > support and indicate the max number of uniflows. Having sets of CIDs per > path seems an unfortunate complication to me, but I haven't thought about > it enough. The two new frames and modifications to the ACK frame are > simple enough. > > Is there MORE work QUIC WG would have to do than what's described in the > draft? If so, can people outline that work? > > This reminded me of the comment I made on the mailing list in January [1] about how QUIC extensions would play together. There was some further discussion on GitHub [2] and in Zurich we decided to do nothing. But we did note that maybe we need to figure things out when the problem comes up, is that time now? Does adopting one extension force people into an uncomfortable position of picking one optimization over another? [1] https://mailarchive.ietf.org/arch/msg/quic/OlwAHMyK2mAuRCRuCP-Lpyb7ntA/ [2] https://github.com/quicwg/base-drafts/issues/3332 Cheers Lucas
