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