Re: New Plaintext QUIC-LB Design

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 11 January 2021 23:19 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746F53A152D for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 15:19:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6zhWOXnMVJf for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 15:19:12 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615A53A152B for <quic@ietf.org>; Mon, 11 Jan 2021 15:19:12 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id p13so822805ljg.2 for <quic@ietf.org>; Mon, 11 Jan 2021 15:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mNgBxLgmqZMafSIg3mrYuym32ND7N1U5NhjRhMwHz34=; b=kGW9Ah3GAT0BDbnBOH4/T5azQRGJWiEBOjErtx+pUPCTvtmzob2LzCOE3iulCFDX2X ApbOVCUCBgvLFpWd0R5Txpr89bRHcnogAE5ZhF87lM8rNyq0IT08aB6/xwnfpSpYDfSH rHTgT93vSIpAlRQwI9X6Ea09eIalM9WJUO2fFQNWtoDCPsfP/SZu4OMT0X2Kq3WoQvqj JvVzgJ+rTXgOuFMG3E9bfbcD8eKRe+8jvl9WnS/VgtjAHHLfljevuUI2XVRveusTcJe1 058r2UGYBDvzeOVogEZQuaSAr4FmvyY4uneDGtZWEa2c8LVbY0p5dzjp6FDyK0E86jjw /hlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mNgBxLgmqZMafSIg3mrYuym32ND7N1U5NhjRhMwHz34=; b=Q0cFv98CIMGX3Z3mvMvLOoum2QZ/AUxPZngTAQpHxOy182PvlUb+TEQ6SFQHGncT5u EYUdEO0oXC5v+tXjYaY024J1Lo7TShbcHmErocNABxOiJk16VmbMhMCF08lU6K4Mw1P6 I6u+DiC/Fat66eoGUspNdL2EGq1sAjGp8W7HPf51jBPWaJPNLIT3F998FxDMa4IFXt2H hQGU6HI7Qlr7DdUqKaaCy9G+rVC2w8hwtK70CcbYGDzd98BmJsy2ysmxDJ8VVIoCpzKX 7SAEYkuiKG/Ji1NqhrKh8QzQSyDGujjmChYTkbW50Fg0oU2WTLTPwIDOcHsdXTFq0K5Y 4bfw==
X-Gm-Message-State: AOAM532cFDAQ+Ko7XT/7BLSpSH8oRsXH9eaz19dm9Ju6KQm0w/5EDDK4 rJr32fnDgEFT/MT8oFwOmIE=
X-Google-Smtp-Source: ABdhPJyDGcSTF3uJHsQaADOWzXI6d58qfUJ+pam8YSmyWyWbM3M1N20bqpBba1WSOrWLXvyeWruovQ==
X-Received: by 2002:a2e:8548:: with SMTP id u8mr741910ljj.17.1610407150351; Mon, 11 Jan 2021 15:19:10 -0800 (PST)
Received: from mobile.3.dk ([2a02:aa7:4604:5103:1d01:5a1e:a05f:e067]) by smtp.gmail.com with ESMTPSA id n25sm149653lfh.177.2021.01.11.15.19.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jan 2021 15:19:09 -0800 (PST)
From: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Message-Id: <6B05568D-1905-4416-904C-2EEC25491920@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_598CC6BD-6A80-4042-80AA-AF60E6C98F17"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: New Plaintext QUIC-LB Design
Date: Tue, 12 Jan 2021 00:19:07 +0100
In-Reply-To: <CAM4esxRRp5=-YvcPsCdsgB=8O=_RAXq05Ldma0smGsjy95T4=g@mail.gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
To: Martin Duke <martin.h.duke@gmail.com>
References: <CAM4esxRRp5=-YvcPsCdsgB=8O=_RAXq05Ldma0smGsjy95T4=g@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Olw-58b9AwFuc45UZ6jtkSalVLM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2021 23:19:14 -0000

I’m trying to read through the LB document that I haven’t looked at for quite a while. It isn’t very clear to me, I am sorry to say.

I do not understand why the highest configuration value is chosen since this value would eventually wrap? Is there an implied wider config value where only the lower bits are visible, similar to packet numbers?

Also, I do not understand how the server receives the assigned SID. Is the ODCID replaced in first packets, or are the packets unmodified, or is the SID prefixed the real packet?

I can see that once the server chooses the DCID for later communication, things get easier.

If the ODCID is modified, what about message authentication, also in future versions and with possible shared keys?

Is the state table affected by the clients choice of ODCID (think abuse)?


Mikkel

> On 11 Jan 2021, at 22.40, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Hi all,
> 
> Ian proposed a radical new plaintext CID algorithm for for quic-lb. I already merged it into the draft alongside the current one, to make things clearer. See Section 4.2 of the draft <https://quicwg.org/load-balancers/draft-ietf-quic-load-balancers.html#name-ecmp-cid-algorithm>. I suspect this may not be the final result, but this is another one of those value judgments I'd like input on.
> 
> TL;DR: instead of assigning individual server IDs as a configuration step, load balancers assign them ad hoc and remember those assignments. Servers can observe their assignments from the CIDs they receive.
> 
> Tradeoffs: The existing PCID design has precisely zero per-connection state at the load balancer. This design requires the load balancer to have a potentially very large table of SIDs mapped to servers. On the other hand, Ian's proposal completely eliminates the process of configuring the load balancer with a server ID mapping, and configuring each server separately with its SID.
> 
> As a practical matter, Ian's proposal is also an easier transition path for Google's load balancers, and presumably others as well. Their implementation experience suggests that the memory load is manageable.
> 
> As Ian’s design has per-connection state, it is less robust to the load balancer rebooting or handing off to a standby device.
> 
> So we have three options:
> 1) Stick with PCID and ditch this.
> 2) Replace PCID with this proposal.
> 3) Have two standard unencrypted algorithms to capture the tradeoff -- I would prefer not to complicate things in this way unless there is real disagreement about how to resolve the tradeoffs.
> 
> Thoughts?
> 
> Thanks,
> Martin