Re: Splitting QUIC-LB into two docs

[Nick Banks <[e-mail]>]

I also agree that splitting is the best path forward.

Thanks,
- Nick


Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: QUIC <[e-mail]> on behalf of Ian Swett <ianswett=[e-mail]>
Sent: Thursday, March 3, 2022 9:10 AM
To: Ted Hardie <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>; Martin Duke <[e-mail]>
Subject: Re: Splitting QUIC-LB into two docs

Thanks for doing this split Martin.  I agree that there's no need for these to be in a single document, because they're easy to separate and two more tightly focused documents are better for all the reasons you laid out.

>From what I read, the split looks clean and sensible to me.

Ian

On Thu, Mar 3, 2022 at 3:49 AM Ted Hardie <[e-mail]<mailto:[e-mail]>> wrote:
Hi Martin,

For what it's worth, I thought the value of keeping them together before was basically that middlebox coordination as a topic would be useful to consider generally and that having two different examples together helped that.

I agree with you, though, that it makes it harder for each individual coordination method to get a clean spec. I took a look at this and the split looks generally reasonable to me.

I think that we might eventually need a third document, which describes the middlebox considerations which are invariant for QUIC.

regards,

Ted

On Wed, Mar 2, 2022 at 11:55 PM Martin Duke <[e-mail]<mailto:[e-mail]>> wrote:
Hello QUIC enthusiasts,

TL;DR
At IETF 112 I proposed splitting the QUIC-LB draft into two documents, to broad indifference. You can see the result in this branch: https://github.com/quicwg/load-balancers/tree/split-docs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fload-balancers%2Ftree%2Fsplit-docs&data=04%7C01%7Cnibanks%40microsoft.com%7Cb6d49f07f6dc4ac2d34708d9fd1f9a1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637819134464378998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9im0Ow4iFX5ptTncco3ng40dCWpT4ZLJ%2FNHahMixEfQ%3D&reserved=0>

If people are generally OK with splitting the load balancing bit and the retry offload bit into separate adopted documents, I would like to merge this change and do the associated datatracker actions.

Longer Explanation:
When Nick Banks came up with the idea of Retry offload, it fit with the general theme of middlebox coordination, so we just tacked it on to our QUIC-LB draft. This has become increasingly ill-advised for several reasons:

- These systems have nothing to do with each other, except for the very high-level idea of middlebox coordination
- It balloons the draft from 35 to 53 pages, which reduces the likelihood of quality reviews
- If the RFC requires an update in the future, more text will increase the workload, and it is unlikely both designs will simultaneously need an update
- There is no reason to think that implementation maturity for the two halves will stay in sync, meaning that one part could hold back WGLC for the other
- The load balancer part is largely version-independent, and retry offload is not.
- QUIC-LB isn't even a good name for the doc if a bunch of it has nothing to do with load balancers
- There are other middlebox-themed proposals out there, like Reset offload<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fload-balancers%2Fissues%2F119&data=04%7C01%7Cnibanks%40microsoft.com%7Cb6d49f07f6dc4ac2d34708d9fd1f9a1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637819134464378998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=H2xF7X6L0rA3QBwSaj2jond3DJpYVvKQ66UXUUN7I%2BA%3D&reserved=0> and Proxy Protocol for QUIC<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fload-balancers%2Fissues%2F51&data=04%7C01%7Cnibanks%40microsoft.com%7Cb6d49f07f6dc4ac2d34708d9fd1f9a1b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637819134464378998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8LPWV7YvPpWTiG1TDVl%2B0zWCiMFF5sDujAKG4sBuMIM%3D&reserved=0>. Without launching a discussion about the merits of these here, if our draft is going to be the receptacle for all middlebox stuff, there will be further bloat. IMO these should be separate drafts.

Anyhow, please take a look at the branch, collect some thoughts, and you can yell at me in Vienna if you find it to be disagreeable.

Martin