Re: New Plaintext QUIC-LB Design

[Behcet Sarikaya <[e-mail]>]

Hi Martin,


On Fri, Jan 15, 2021 at 7:09 PM Martin Duke <[e-mail]> wrote:

> I've been playing with Ian's algorithm (specifically, the way I had to
> modify it to fit into the QUIC-LB framework) and filed an issue.
>

What is QUIC-LB?

Is it public domain?

Behcet

>
> https://github.com/quicwg/load-balancers/issues/84
>
> This is very long and hard to reason about, but the upshot is there are
> significant problems and without some clever design I'm not sure how to
> make this work.
>
> On Fri, Jan 15, 2021 at 12:26 PM Mikkel Fahnøe Jørgensen <
> [e-mail]> wrote:
>
>> There is also
>>
>> https://en.wikipedia.org/wiki/Rendezvous_hashing
>>
>>
>> On 15 Jan 2021, at 21.18, Mikkel Fahnøe Jørgensen <[e-mail]>
>> wrote:
>>
>> I would be hesitant to introduce a situation where a load balancer is
>> forced to use memory, especially memory it doesn’t fully control. It may be
>> fine as a choice, but not the only choice.
>>
>> Aside from potential attacks, there is also the hardware cost/complexity.
>> SHA256 and AES is pretty standard in almost anything, but lots of RAM is a
>> cost driver.
>>
>> It is really hard to estimate crypto vs lookup overhead, but it is far
>> from a given that lookup will be faster once the tables grow large.
>>
>> Less coordination is a good thing though. I’m afraid that without out of
>> band payload to coordinate, there will have to be a choice between
>> configuration and state.
>>
>> Mikkel
>>
>> On 15 Jan 2021, at 21.04, Martin Duke <[e-mail]> wrote:
>>
>> To muddy this discussion a little further, after a little more thinking I
>> believe there's a way to generalize this approach to all three of the
>> original algorithms, encrypted or unencrypted, so there is never a need to
>> manually allocate server IDs.
>>
>> Again, the main tradeoff here is simpler configuration vs. more
>> complexity and state at the load balancer.
>>
>> As a document organization matter, rather than have six different
>> algorithms I would prefer to specify three with a separate section
>> describing the two separate ways to allocate a server ID.
>>
>> But it is not too late to yell "stop" at this multiplicity of options if
>> people feel the tradeoffs are clear-cut in one way or the other.
>>
>> On Mon, Jan 11, 2021 at 6:50 PM Martin Duke <[e-mail]>
>> wrote:
>>
>>> Yes. Do you have an alternate suggestion?
>>>
>>> On Mon, Jan 11, 2021 at 5:54 PM Christian Huitema <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> On 1/11/2021 5:22 PM, Martin Duke wrote:
>>>>
>>>> Perhaps I should make some edits for clarity!
>>>>
>>>> On Mon, Jan 11, 2021, 16:52 Christian Huitema <[e-mail]>
>>>> wrote:
>>>>
>>>>> I am looking at the text of section 4.2, and I am not sure how I would
>>>>> implement that. What should be the value of the config rotation bits in CID
>>>>> created by the server?
>>>>>
>>>> Any config includes the corresponding CR bits, and when generating the
>>>> CID it would use those bits.
>>>>
>>>> The confusing part is that, for this algorithm, a usable SID has to be
>>>> extracted from any CID, hence all the weird stuff about CIDs with undefined
>>>> configs.
>>>>
>>>> Aside from that, it's like PCID: any server-generated CID uses the CR
>>>> bits in the config, optional length encoding, SID, server-use octets.
>>>>
>>>>
>>>>> Should the 6 other bits in the first octet be set to a CID Len or to a
>>>>> random value?
>>>>>
>>>> It depends on the rest of the config, as with the other algorithms.
>>>>
>>>>>
>>>>> Issss the timer set when the server ID is first added to the table, or
>>>>> is the timer reset each time a packet is received with that CID? In the
>>>>> latter case, is it reset when any packet is received, or only when a "first
>>>>> initial" packet is received?
>>>>>
>>>> When any packet is received with that SID (not CID), the expiration is
>>>> refreshed.
>>>>
>>>> OK. So we can have the following:
>>>>
>>>> 1) Server learns of Server-ID = X.
>>>>
>>>> 2) Server creates new CID with that server ID, uses it to complete
>>>> handshake.
>>>>
>>>> 3) Client maintains a long running connection with that CID.
>>>>
>>>> 4) Server keeps receiving messages with CID pointing to server-ID = X
>>>>
>>>> 5) server-ID=X never expires.
>>>>
>>>> Is that by design?
>>>>
>>>> -- Christian Huitema
>>>>
>>>>
>>>>
>>
>>