Subject: Splitting QUIC-LB into two docs

From: Martin Duke <[email-masked]>
Date: Wed, 2 Mar 2022 15:55:17 -0800

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

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://github.com/quicwg/load-balancers/issues/119> and Proxy Protocol
for QUIC <https://github.com/quicwg/load-balancers/issues/51>. 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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 3 Mar 2022 08:48:48 +0000

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

---

From: Ian Swett <[email-masked]>
Date: Thu, 3 Mar 2022 09:10:08 -0500

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 <[email-masked]> wrote:

> I think that we might eventually need a third document, which describes
> the middlebox considerations which are invariant for QUIC.
>
> regards,
>
> Ted
>
>> - 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
>> - The load balancer part is largely version-independent, and retry
>> offload is not.
>> - There are other middlebox-themed proposals out there, like Reset
>> offload <https://github.com/quicwg/load-balancers/issues/119> and Proxy
>> Protocol for QUIC <https://github.com/quicwg/load-balancers/issues/51>.
>> 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.
>>

---

From: Nick Banks <[email-masked]>
Date: Thu, 3 Mar 2022 17:09:49 +0000

I also agree that splitting is the best path forward.

Thanks,
- Nick

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

________________________________
From: QUIC <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
Sent: Thursday, March 3, 2022 9:10 AM
To: Ted Hardie <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Martin Duke <[email-masked]>
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.

Ian

On Thu, Mar 3, 2022 at 3:49 AM Ted Hardie <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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