Re: QUIC Invariants and QUIC-LB

Martin Duke <martin.h.duke@gmail.com> Fri, 22 May 2020 15:52 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 D1A463A0B96 for <quic@ietfa.amsl.com>; Fri, 22 May 2020 08:52:56 -0700 (PDT)
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 qPx93bpycUIj for <quic@ietfa.amsl.com>; Fri, 22 May 2020 08:52:55 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 2384B3A0B95 for <quic@ietf.org>; Fri, 22 May 2020 08:52:55 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id 18so11152725iln.9 for <quic@ietf.org>; Fri, 22 May 2020 08:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/1LFp5K1MGapkgLIjGcn60Yfyq+g6lEIxa6jafLMJCw=; b=lqKPoRbzYTn3RYLME6ZlOLnT5UJWoKiux9LXVm4mQ2EKiQw6I5PEJBxX0xvXkBWUiw TP0HAngD7Quxir4b+Af2OUznIcbHXyIjW2gecD/yTMn8+8BXUr2PAIRTXuWlv6VijieC iasIjxcMBObVGbCeoVOzjMr031Pl2DZvBNv0e3sZeMHoaobFFknMgy0GeF98qzWfrlb5 XhkWtT4Ler58UXXbMm+Xzcoegi8jMouTo7uK4Fb1Or4/+5i5OK1ofFBvfZWh76iJKMBc 10Y80cTZOw282NinAf2rSHJCpJLp+1sIKr6G7+qVKR/STxU1Lne9glOZVdSAus+DSODw 6aCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/1LFp5K1MGapkgLIjGcn60Yfyq+g6lEIxa6jafLMJCw=; b=V0uWVc/I9+Imw5Ry05GN3JIKxfN9NaUpB7bc3/bc0AecHG5JDw9PptuKewcES3DhrJ BieKQPS1YvPFWFeOccRyBEk+td6U0mv2CEufrDYMG6k+26rflsu1a61XSysHKdqSC9UD SXW0y09D7xA5sZTYWilHSwc/bH95JEnf0DPGHWtibBdnpGqTYoxsc/jY60oGZ9mJUTby JZCSCLsIyMlwRQoNG9Zn853XSxc8urqLGGRotAkYOWCYUObPgAE6y0fc6KkF5ZY9f8XT WCH7d/1i8bBcZ4Y0NvEILHahVCmAN1gE/f+xxv9d9vPFty5/7w8AzuW4m/ri0MtMlGD+ c9/g==
X-Gm-Message-State: AOAM5304JrvX4OQUna7a0rmw2U/1+c83naF8SGG8VJSU9rm68y3QGS4i AJonr5FGDV1ev41/aKISoGKgmFwRgz4UWfWDmRI=
X-Google-Smtp-Source: ABdhPJxhUQ9e13don9l/1M7HijrNZGqJIcANfMxItuc0C+R4+3qNBt38G1uR68BhUlICvqmlrra3MAfYyFDOq3S8FvE=
X-Received: by 2002:a92:5c89:: with SMTP id d9mr14126023ilg.237.1590162772474; Fri, 22 May 2020 08:52:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxTW2rWTAuLfbNuLYocefoMUwUzKzUre+2brFiHC9HZZTw@mail.gmail.com> <CAKcm_gP27qgOwa9P-dYq89+KB_V-6oaaWdzmYF9fGBqhpwYQmQ@mail.gmail.com> <8a4d170b-ce42-443a-82fc-ebd57222d07a@www.fastmail.com> <CAM4esxSHKCSP=cMQYV1HcGtDbMcvumOR_7wGhOu3dF2o2KPQiw@mail.gmail.com> <6f663b55-00b3-4566-bf18-b3b350c00605@www.fastmail.com>
In-Reply-To: <6f663b55-00b3-4566-bf18-b3b350c00605@www.fastmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 22 May 2020 08:52:39 -0700
Message-ID: <CAM4esxTusCCiiaAJ22hfxWoZ5J_q9Bd1t73tdZBmmOA-nWP8-A@mail.gmail.com>
Subject: Re: QUIC Invariants and QUIC-LB
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000351ed305a63e9fa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RFVKQxpLObgh1D_eJEhNSOrjCsg>
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: Fri, 22 May 2020 15:52:57 -0000

Filed  https://github.com/quicwg/load-balancers/issues/22 to use Martin's
recommendation on fields likely to be stable.

On Thu, May 21, 2020 at 8:12 PM Martin Thomson <mt@lowentropy.net> wrote:

>
>
> On Fri, May 22, 2020, at 10:00, Martin Duke wrote:
> > I don't think we're going to get a 100% version-invariant QUIC-LB,
> > though we're pretty close.
>
> Yep.
>
> Based on this discussion, what I think is happening here is that we're
> defining a new set of invariants: the set of things that we can't really
> change between versions that support the same load balancers as QUIC
> version 1.  That this is a superset of the invariants work is a bit
> unfortunate, but the difference is small enough.
>
> > It would be nice to give LBs somewhat more specific guidance for what
> > fields they can use for packets with non-compliant DCIDs. For example,
> > if we could at least safely assume the DCID won't change until the
> > server provides one, that would be way better than forcing them to make
> > assumptions about IP and UDP fields remaining stable.
>
> Based on invariants + LB-invariants, I think that you have some good
> advice already:
>
> If you didn't create the DCID, then apply some sort of "default" routing.
> That routing will rely on the stability of a subset of fields.  I would
> select from (source IP, source port, destination IP, destination port,
> DCID) and no others.  Nothing else in the QUIC packet is good, except
> *perhaps* the version number.  Without understanding the version, SCID is
> totally out as it isn't guaranteed to be stable.  Add anything that isn't
> stable and you might get problems, so while I can see a case for including
> something like the IPv6 flow label, that's risky.
>
> Generally speaking, it should be enough to route based on DCID alone, or
> to route just on the source address, but the more (stable) fields you
> include the more you allow concurrent connection attempts from the same
> address.
>
> Finally, to speak to the first assumption, if it is a short header, and
> you decide to use the DCID for routing, then you are OK throwing the packet
> away, because you don't know how long the DCID is.  Similarly, if the DCID
> is empty and you need it, then throwing it out is justified.  But you can
> do QUICv1 without either if you only use addressing information, so that
> wouldn't need to be the same for every load balancer.
>
>