Re: [quicwg/base-drafts] Reserve Long Header Packet Type for QUIC-LB (#1980)

[Nick Banks <[e-mail]>]

@janaiyengar my understanding is that the current goal for QUIC-LB is to get it adopted by the WG ASAP (@martinduke please correct me if I'm wrong). Also, I'm not explicitly asking for a new value to be reserved JUST for QUIC-LB, just that we have a provision in the transport to allow something else to use another value.

@martinthomson the entire goal of the QUIC-LB draft is to define a protocol to allow load balancers to configure backend servers, with the primary goal focused on configuration for CID routing (though it may be used for other things in the future: RETRY token encoding, 0-RTT ticket keys, ...). We aren't worried about how the configuration packets are going to be routed to the backend servers. Obviously they can be sent directly. As I stated before, they don't even have CIDs in them anyways. These packets don't create connections between the backend server and load balancer. It would be possible to not use special QUIC packets, but instead to design the protocol on top of QUIC connections, but that would add a LOT of extra complexity. Right now, no TLS is required. Another goal for this protocol is to have it easily implementable in hardware. 

As to the possible ossification downside of this, I agree it could be a concern. As QUIC-LB's intended use of this is just between the backend server and load balancers, you'd never see this value on the open internet. Perhaps it can be reserved and greased on the open internet. IDK...

@martinduke I agree that we have a last resort of repurposing the RETRY code point to our own purposes, but that seems really ugly from a design and an implementation perspective. I'd really prefer to only do that as a last resort.

-- 
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/1980#issuecomment-437922256