Re: New Plaintext QUIC-LB Design

[Martin Duke <[e-mail]>]

Hi Behcet,

QUIC-LB is QUIC Load Balancers, the draft we've been talking about this
whole time:
https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers/

On Mon, Jan 18, 2021 at 8:04 AM Behcet Sarikaya <[e-mail]>
wrote:

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