We may not be able to use a fifth packet type

martinduke / draft-duke-quic-load-balancers

An internet draft to standardize the way that QUIC servers and load balancers can support routable, unlinkable connection IDs

Other

2 stars 4 forks source link

We may not be able to use a fifth packet type #9

Closed martinduke closed 6 years ago

martinduke commented 6 years ago

Martin Thomson's new first byte proposal would eliminate any extra QUIC long header codepoints that we are currently using for QUIC-LB.

This is not yet final, but are there other mechanisms we could use? One would be to use the RETRY type: if a server receives one, it must be QUIC_LB. A load balancer would probably be able to disambiguate this as well. But it is kind of gross.

nibanks commented 6 years ago

I'd rather argue to get a packet type reserved in the transport spec. I don't like reusing the Retry packet. It is an acceptable last option though.

nibanks commented 6 years ago

Should we open an issue on the transport doc to request a packet type to be reserved?

martinduke commented 6 years ago

I emailed Martin T. for guidance about how to proceed.

nibanks commented 6 years ago

Any more updates on this?

martinduke commented 6 years ago

M.T. was inclined to just have us use some of the non-QUIC codepoint space in the first byte. As the change to QUIC hasn't landed I think we can leave this as a placeholder for now.

dtikhonov commented 6 years ago

The idea is to make QUIC-LB packets look like QUIC. It would be a pity to lose this useful property.

nibanks commented 6 years ago

I agree that we definitely should push to make sure QUIC-LB packets can be easily processed by the backend server just like any other QUIC packets.

martinduke commented 6 years ago

I am keeping this issue open but will not press it until MT lands his redo of the first byte. If anyone else wants to nag him at a meeting, be my guest.

dtikhonov commented 6 years ago

I am keeping this issue open but will not press it until MT lands his redo of the first byte.

Do you plan to advocate for the fifth byte before the WG? Recent activity on the mailing list suggests that new transport change proposals will face significant hurdles. If MT is not willing to add the fifth byte into his pending first byte change, the upcoming meeting may be the last chance to get the fifth byte approved.

nibanks commented 6 years ago

I agree. I think we should explicitly open an issue on the transport now. I see the following as possible changes to the transport draft:

Explicitly define a generic QUIC-LB packet type but defines no message types.
Just reserve a value (or range of values) that we can then use.

I prefer the second one so we don't have to finalize any of the QUIC-LB formatting immediately for the transport spec. I believe if this issue is opened, and enough of the LB folks chime in and +1 it, it probably would get accepted.

martinduke commented 6 years ago

Sure, let's file an issue for a reserved codepoint. Until adoption I don't think we can do much more than that.

martinduke commented 6 years ago

Sounds like M.T.'s first-byte rearrangement is going to happen. Can someone file the issue vs. quic-transport.

dtikhonov commented 6 years ago

Either of you gentlemen carry more clout than I do.

nibanks commented 6 years ago

Done: https://github.com/quicwg/base-drafts/issues/1980

nibanks commented 6 years ago

As discussed in the base-drafts Issue, we will have to use a different version number for QUIC-LB instead. I don't think that will be a big deal. I can write up a PR sometime this week most likely.