Retry Services in a different draft

[martinduke]

Upon further reflection, it may be better for Retry Services to be in a different draft. The main reason is that CID encoding deals with the CID, which is an invariant part of QUIC.

Meanwhile, Retry services are most definitely version-dependent. It would be annoying to have update all of this stuff based on QUIC version revs that changed the Retry semantics.

On the other hand, it would be a bummer to have two separate chunks of configuration, particularly if it was happening in-band.

Thoughts on this? I'm inclined to separate out the drafts before Singapore.

[ximaera]

After an hour of intensive clicking through the e-mail archive I think I won't be taking any side here.

As is probably obvious from the conversations happening in the past, I generally support the idea of refining Retry Services further. OTOH I'm concerned about the separate Retry Services draft possibly ultimately never making it to the IESG b/c only a fraction of the working group members would be inclined to work on that while the rest of the WG would hardly have any interest in even advancing it through the IETF process.

[nibanks]

For me, because Azure will only be one side of this protocol, I really want a standardized protocol (ideally at the QUIC server level, but I'm open to other possibilities here) for communicating all the configuration necessary for a load balanced server in a cloud environment.

One possible way to achieve this is to have one big spec for both the configuration protocol (the actual communication between the backend server and infrastructure) and all the actual features that get configured (CID load balancing; Retry service/offload; Key management (0-RTT/stateless reset); etc). The other option I see is to break up all the various pieces in different specs.

I personally would prefer to reduce the process overhead and have a single spec, and allow for extensions to that spec, but I'm open to discussion.

[ximaera]

Nick,

because Azure will only be one side of this protocol

Could you elaborate which "sides" do you mean?

[nibanks]

Azure is the infrastructure side here. It will be the load balancer. It will also have/be the retry service. It needs to be able to communicate with any QUIC server/implementation running in its cloud.

[ximaera]

Ah, fine.

IMO it may in fact pay back to give the idea of separating configuration provisioning from data communication (in pretty much the same way as control/data planes are split in the network equipment) a shot.

[janaiyengar]

There's cost in maintaining multiple documents, and the draft isn't unwieldy enough to justify that cost. I understand the functional line you're drawing, but I think it's still early days for the draft.

I don't feel strongly about this, but I wouldn't worry about the cost of rev'ing drafts along with QUIC versions... the changes can be to one part of the draft, and that's fine. All implementers will have to consider both CID encoding and Retry anyways, so there is quite a bit of value in keeping it all together.

My suggestion, which is not a strong one, would be to keep it as it is, especially since we expect churn here as the draft goes through the wg post-adoption (when that happens).

[martinduke]

Thanks for your comments. I'll leave everything integrated for now.