Re: New Plaintext QUIC-LB Design

[Martin Duke <[e-mail]>]

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