Re: draft-duke-quic-load-balancers-00.txt

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 14 February 2018 09:16 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 0CC19126D46 for <quic@ietfa.amsl.com>; Wed, 14 Feb 2018 01:16:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 DWS8vhI-NOhk for <quic@ietfa.amsl.com>; Wed, 14 Feb 2018 01:16:31 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 854B8128961 for <quic@ietf.org>; Wed, 14 Feb 2018 01:16:24 -0800 (PST)
Received: by mail-io0-x229.google.com with SMTP id f4so24450952ioh.8 for <quic@ietf.org>; Wed, 14 Feb 2018 01:16:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=jxkKDwo7dwiVBfQfcADC7fM8dxMJA5OK7/6Trp42b1Y=; b=k+SC/36UazPOC00qJAl65LXp8mDlGFnYUtvTnUFKxa7BFejJhoj0Sj7jS1Dfm2F6Ie z+2k0GafNoOSh7N09lK3/5K1yMptsChCGMOn5F0tAiREBLZ7Igfr1YYkfSOOifVncbJT Qcfd2Rje3HtnFdFx9MjhCTp71+KQk0gfa4eIYPe1qwevX694ri73eTt8ryRP4YFgC8Sj p51/mZxJ3SOxf28FoYCeUPKvhlJvuV9atfP0L5nGVgH1Vw8qmj4LfrmS0OLksQc8ndB4 ni7PvFL7BlSzELkhAnoXZ3Qyu2EQjR7izbXCpY8SNra3OV37ATguJuEJlRAYMkpCSYT2 naKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=jxkKDwo7dwiVBfQfcADC7fM8dxMJA5OK7/6Trp42b1Y=; b=LkAPJWO9eTidvnxPF7PQ0fHGTqEX90smlqQuyli+/iaOsmBlkQJWtcL4MssrHL+BjN zT157k4ldh+loDjYGUoDIc9Wqss9eg9Sk5IMQ5rPVERGG+6lQ2JxKWmqux+iMa2HxxMw +V+cI2X/oZBUTJoH7/B6J2TSiDCz0PIWN7C2GhRSg9U6GeOei7GQrmLgekb8N1PxYQCi QGlSXDz94i1jwz8E8K0cYG9UOBt3P6h0Wlzbkym1onvr4sfg3/DQcEIfnDHd8ICmZ25r J2Bc9rBPMEqs1+eP4/iO/ScGpcZrwinlm3R2QX9DaziqBLr2iiGOqWSdtXJzHqSocwP7 9TuQ==
X-Gm-Message-State: APf1xPA74H1QYgXqT+NVop08XGEShcxgDI6QUDkH+GoKXN+zR3EMZhLp EtlqZVJuzh38Ta2xqZm2qMlpaxEfkaz0R2fbY3g=
X-Google-Smtp-Source: AH8x22447eD7DvA0TEeXhB3fPgL7BcrkBdF2xE/N2S7KqkJoQIYpXy1PYXWkNadVHbAWndUk/Bzbip+oaMqKQBJbgJw=
X-Received: by 10.107.168.31 with SMTP id r31mr4543935ioe.16.1518599783916; Wed, 14 Feb 2018 01:16:23 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 14 Feb 2018 01:16:22 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CAM4esxT-7ZLQx2q_bzkjDc3+pv+x6eB6vz5Gm9f-PYHsiKu6cQ@mail.gmail.com>
References: <CAM4esxRq131G7XOC1YNy6N943Bar08gh8vMmhU34-vYcXOAauw@mail.gmail.com> <CAAedzxrdwHOKhXKxN90yxWh1Zcb3wmHtktMnGPXsCkXNDB6DpQ@mail.gmail.com> <20180213215453.GA6686@ubuntu-dmitri> <CAM4esxT-7ZLQx2q_bzkjDc3+pv+x6eB6vz5Gm9f-PYHsiKu6cQ@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Wed, 14 Feb 2018 01:16:22 -0800
Message-ID: <CAN1APdfHXKLDwzH9gRGuR13q-v5ATZ8TTHRd9HnzJBh-OfN1Lw@mail.gmail.com>
Subject: Re: draft-duke-quic-load-balancers-00.txt
To: Erik Kline <ek@google.com>, IETF QUIC WG <quic@ietf.org>, Martin Duke <martin.h.duke@gmail.com>
Content-Type: multipart/alternative; boundary="001a11427686ad2ba505652890a8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cGS-YCw8CCLY6S6COZBi9RcAXQE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 14 Feb 2018 09:16:33 -0000

I was also wondering about why not using QUIC, but a load balancer does not
need to understand QUIC to route QUIC, especially not with this protocol.

But it complicates QUIC endpoints having to deal with another crypto
transport mechanism.
I don’t think the argument of keeping routers simpler is very strong - it
may be true short term - but eventually routers will understand QUIC.

A downside to using QUIC is that routers may stick to an old version of
QUIC for a long time.

One could imagine a set of central control servers providing CID’s rather
than the QUIC server itself - this would remove some of the versioning
concern, but then bother router and QUIC server would have to connect to
the central control system. This isn’t so different from a MQTT
configuration and would simplify the configuration matrix.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 14 February 2018 at 04.49.17, Martin Duke (martin.h.duke@gmail.com)
wrote:

Oops, I didn't reply all. Repeated below:

Hi Erik,

That would certainly work. In TCP the load balancers we make have
"monitors" that open up TCP connections periodically with servers to make
sure they're there and functioning.

My thought was that a full-fledged QUIC client implementation might be a
little heavyweight for some of these devices. Certainly, if you have an
existing Linux L4 load balancer and are looking to write some lightweight
code to support QUIC, you probably already have the DTLS APIs you need
there. But I am perfectly happy to go with the consensus here.


On Tue, Feb 13, 2018 at 1:54 PM, Dmitri Tikhonov <
dtikhonov@litespeedtech.com> wrote:

> On Mon, Feb 12, 2018 at 05:34:46PM -0800, Erik Kline wrote:
> > I wasn't in Melbourne, but I'm curious: why not specify a protocol
> > over QUIC itself?
>
> +1: As I was reading the draft, I was wondering the same thing.
>
>   - Dmitri.
>