Re: Splitting QUIC-LB into two docs

[Ian Swett <[e-mail]>]

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]> 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]>
> 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
>>
>> 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
>>
>