IETF Logo Mail Archive

Re: QUIC servers and enterprise multihoming

Robert Raszuk <robert@raszuk.net> Fri, 28 October 2022 08:55 UTC

Return-Path: <robert@raszuk.net>
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 C581EC15259B for <quic@ietfa.amsl.com>; Fri, 28 Oct 2022 01:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLcdSeI3Xadv for <quic@ietfa.amsl.com>; Fri, 28 Oct 2022 01:55:43 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E331C152592 for <quic@ietf.org>; Fri, 28 Oct 2022 01:55:42 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id t25so11414861ejb.8 for <quic@ietf.org>; Fri, 28 Oct 2022 01:55:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dtCxQ456SwDF9Qvuy4a2G6ipK3S5/P9E+m1QMpSmUYs=; b=YNIjH7j8xLZ6MznWU0t8I6X8/JvwKklZ72Lk6ECax6MU0LNxskInAQzRBu7cB2o5TK 8VGzWJeVHNbLpCJYvx4S4UguRJKEYw1L8GKr1WXwxzkJy0ZOIRUehLqaGdE9QjnwcJ2/ q0RlE56PMsBYcGcLY+Cbm8Bxo2IRDz/q9xAdXFoaFmdheLoDhCgYcEEGveTkBB4dOkyz LxDJgt8p53wy5/oIStkViOAxZ1+lXy5svlVe1kzidPgRy4/vz+uWwPcWc0C222dA4Ra0 FLBwnLd4Dh3KNT+KqqlRNyzf839ppVe/lt748pRpZfJ9IzKR4fvkbApRCxWuzrlzzSU3 WN+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dtCxQ456SwDF9Qvuy4a2G6ipK3S5/P9E+m1QMpSmUYs=; b=1aZm3V04Y1Tn8br11fXCCDJ5Aep9JqpzJ/vZ2uKT/eNErfBVrDRlVZ7hDiQ/zKZPdD qmaN3q8Ln7NsRU4RTWyIvdHtV2HTOh1S7HCnRWUmTR5IcXYYuTMCTqMuJQ8yZL5HadHW f9r1D+4jCuQxuw4CzCmjUxTYNzzxT4RrcCkprtv8s9Z9Jw24S/8rNVOm6ml/Igi2PQLw Uh0aE6utzPBq1/mw4Ps6knpfgk0AbBh4wJnSvpL62soqsTcET7fDGHDRJIkGZYs1xDrL ZSzj0wyvB1m6GPGjVsQhYeigoxNbtkhtKgv3kUMn5zxMIsj6jBxhevdYF9W+RzcEwh4q lyUQ==
X-Gm-Message-State: ACrzQf2oybA3+lG7MzoKJ8fCjgkLeeBg8sQl2uD3GtjWPVXsyhZiZvJt Ek9Fqi0uzeOSasDDMfyuD9FQEXpZ1+dPjbt4KUb5ng==
X-Google-Smtp-Source: AMsMyM7sfdwAex2yZeH4qsaRRHlW4E4NYsyYPlarcfofaDd+I7hJ8Oa1iTnTmPWek9m8XwKNuL9ySvfPAtFMWoC8zQ0=
X-Received: by 2002:a17:907:970b:b0:78d:8d70:e4e8 with SMTP id jg11-20020a170907970b00b0078d8d70e4e8mr44621876ejc.614.1666947341229; Fri, 28 Oct 2022 01:55:41 -0700 (PDT)
MIME-Version: 1.0
References: <d7527d97-402e-d27c-e4f6-d08fa7e13507@uclouvain.be> <CAOj+MMEmgBnyqs3WvkziECVW23Zk-Nn6tEkt4Ms5XvaAKoU71w@mail.gmail.com> <42a43ee8-898e-c97b-6cda-6bdd075a97f7@uclouvain.be>
In-Reply-To: <42a43ee8-898e-c97b-6cda-6bdd075a97f7@uclouvain.be>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 28 Oct 2022 10:56:43 +0200
Message-ID: <CAOj+MMF0+VER-s9ENLc5bwhiLNZAmhRTVDEfcBymROApMwi_Yw@mail.gmail.com>
Subject: Re: QUIC servers and enterprise multihoming
To: Olivier.Bonaventure@uclouvain.be
Cc: RTGWG <rtgwg@ietf.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002236c805ec146cee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Z4pSInPEg6DL54F84__pvUnO2Fg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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, 28 Oct 2022 08:55:47 -0000

Hi Oliviere,

> This is typically what sysadmins do when they configure web servers or
> other types of servers

Well I meant obviously to ask for other non active IP:Port pairs to be
advertised on active session

> > 2. Do you envision that such addresses may span multiple servers ?
>
> Anycast setting is a load balancing problem that is the target for
> QUIC's preferred address transport parameter

That question was not related to anycast at all. If you allow to advertise
IP:PORT pairs for a service there is no need for anycast.

> The problem is different. A load balancer is typically a single address
> served by a large number of servers.

Well nothing prevents you from running a local process acting as LB/traffic
director on a server too.

Thx a lot,
R.




On Fri, Oct 28, 2022 at 9:25 AM Olivier Bonaventure <
Olivier.Bonaventure@uclouvain.be> wrote:

> Robert,
> >
> > Many thx for sharing this proposal. Three easy questions ..
>
> Thanks for your comments
> >
> > 1. Do you envision that IP:PORT pairs would be manually configured by
> > the operator ?
>
> This is typically what sysadmins do when they configure web servers or
> other types of servers, they indicate in the configuration the addresses
> and port the server listens to. On a multihomed server, they either
> indicate they the server should listen to all interfaces or a subset of
> them. This configuration already exist.
>
> > 2. Do you envision that such addresses may span multiple servers ?
>
> Anycast setting is a load balancing problem that is the target for
> QUIC's preferred address transport parameter
>
> > 3. Isn't this a bit overlapping (or to say stronger replacing) function
> > of load balancers ?
> >
>
> The problem is different. A load balancer is typically a single address
> served by a large number of servers. This is currently the main use case
> for QUIC. This is discussed in
> https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers
>
> In the draft, we focus on isolated servers. These could be web servers
> in companies or or example file servers that are running SMB over QUIC
>
> Best regards,
>
>
> Olivier
>
>

v2.23.0 | Report a Bug | By Email