New Plaintext QUIC-LB Design
Martin Duke <martin.h.duke@gmail.com> Mon, 11 January 2021 21:40 UTC
Return-Path: <martin.h.duke@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 92FBC3A12FC for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 13:40:45 -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 ql6k_34pnv0B for <quic@ietfa.amsl.com>; Mon, 11 Jan 2021 13:40:44 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 E5E883A12F7 for <quic@ietf.org>; Mon, 11 Jan 2021 13:40:43 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id d9so63812iob.6 for <quic@ietf.org>; Mon, 11 Jan 2021 13:40:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hhEdVVQmhBWpbhpb5Rx7BawCoUJFoBtWVjUuUJj3kWc=; b=DuLa1aG+tzV2kNi0ddKKYu9mua2Wr6IuRoMJC78M6iU4xWMujd0IsIG6Tku7ZrVjA9 KQC4GVoOh9eQjXtrQzDWJwhGaSym54eN+ewHp9CF25tGiL6fW6/gAje1FXdSaTjzORwh H9qek5iZrHH/vSmBGXDc1Ktp6rfUjM9b7BESyXacJTvkus7jJPjdnYDbS4m0U5FxWNU5 6MCxN4nGEhCSAQqju3626JDNnqeh6/dRH29FpgLCX/jNaY7U0wIxbkXtPN4c3IjLBKDF kvpoLJipnyxguOuQem/xcbqaCvKkNkVJbsfkBcMpHm3C+LlkAGU9LKkOwqRWss3sWI/9 wTuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hhEdVVQmhBWpbhpb5Rx7BawCoUJFoBtWVjUuUJj3kWc=; b=mvUHmarTmHK62WbRRO0C8XXq7Ouvc5le2P6T9g8FCB7NKQdErUFhVoFcPF0Ls1jGpe qKpigmZkJc2tGFZvVo3vrWgwVIxeWKan3C5NjanM+bd9sUxkpzgfoWOSAGTHf8DzBlH5 X46VbwMU5QiadfhxWzq2O7h/3ABPgc92qme/kygNjwff4uaB/jZpO6kmo68zfOpbZwKQ jOgOIlD+QOgjz8hPVYSEWmz0OLqxGFqOw9OCPdka2Z9tDMk/qv9g9ZpBW3SfvCG7s9n/ 2YQ8aR1Zc29/149/qnREPY++1+nqxJxdrU8ysDMdQFBleAddVQJyLlqwd25KpphaZmiQ OQmQ==
X-Gm-Message-State: AOAM530cuDAFq4/skCpIitTxr52VZUPebieTj+cIBS4E6SEQuyP/X13w RhRRugRTUGljO2xI39j0oEuNS/Te7RnXrV0l1iUjUMpO/2M=
X-Google-Smtp-Source: ABdhPJyjZ3cdZfMV4upIEpPruHHlqw9X7G3lFfr0qqXU+BKHVDIC+VN8+BPcRxwh6ZNblJAOsUM4WtTkR9Ul7o9Pogg=
X-Received: by 2002:a05:6638:1247:: with SMTP id o7mr1455206jas.31.1610401242582; Mon, 11 Jan 2021 13:40:42 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 11 Jan 2021 13:40:41 -0800
Message-ID: <CAM4esxRRp5=-YvcPsCdsgB=8O=_RAXq05Ldma0smGsjy95T4=g@mail.gmail.com>
Subject: New Plaintext QUIC-LB Design
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002919005b8a6c23e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/eAKxGJ2EhnMmqHoawM5Ja55lnjY>
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 21:40:46 -0000
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
- New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Dmitri Tikhonov
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Christian Huitema
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Christian Huitema
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Nick Banks
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Mikkel Fahnøe Jørgensen
- Re: New Plaintext QUIC-LB Design Martin Duke
- Re: New Plaintext QUIC-LB Design Behcet Sarikaya
- Re: New Plaintext QUIC-LB Design Martin Duke