[dispatch] HTTP, QUIC, proxies, and HELIUM

Ben Schwartz <bemasc@google.com> Mon, 20 August 2018 19:27 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C3129619 for <dispatch@ietfa.amsl.com>; Mon, 20 Aug 2018 12:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8yQkmLqKGGlv for <dispatch@ietfa.amsl.com>; Mon, 20 Aug 2018 12:27:43 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 92DFA128CF3 for <dispatch@ietf.org>; Mon, 20 Aug 2018 12:27:43 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id d9-v6so955312itf.2 for <dispatch@ietf.org>; Mon, 20 Aug 2018 12:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=01w1168HPSSyACTov6YNAneiiDZzq1MOohVYau3d2x4=; b=U4s5PhiY+Eewi3qh92fL14XCjipnBh7P9KOD0uwlVFDNIUAjELJXGunUP1Mhy6MHVi VfNOmpySuUUlKXbow+FIFGVcA8OtvWXsV8o4B25u0ALQUH4m00QBVlwjpqrH8Et4JAQF fTcES0tO5AiKgb8cTktP8X8NmIXnzlxjXXhPIXhNy4SC4hI+p/5nu1FrG0qKgJDpn3GA 0ZJzcVlCPqu6PSu8ywyUnhdJ15CwRrmfTFMH53RmF5DOHeMJHMGXmJYqxto7lqmaWrNk 3lnQ0DcjvhdsIt4rs4Fj4rLLAt7hLqFTbw10HjxQZgB1zauZNLdHjhG3Z31b6IDwCYYO VjDw==
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:cc; bh=01w1168HPSSyACTov6YNAneiiDZzq1MOohVYau3d2x4=; b=H90Mqew/QjbP8/KSUHU1lr/vVsyTulxb8s9pbcdz75L9LbfY4rvO7DoAaev3iLjPu1 nw63OgGbOss7nSoSOrkkW1sD81oVWhjL+rpfqr1AvP1oeIgmIGZnagJ42dO+OJELSFzf 9GsXUT895qq71mYsVUXnmagswDxLv3Ny9P4C+uYjw94YKRWMYA5h3W0Ws2IpStR/jeMT xpeqYB4phJqF7R1a9GvmMU9zLLL5H4/nEMnrJizzuXvC0AvmpSJxf0QSjQj8GVDlDQbk Hf31O+wj4NC/XV1OOG6/1qCA0+qxrn9W/CN0KGJgd4EFQZvXyqr/Yqry75/H/AiZt1rE D2AA==
X-Gm-Message-State: AOUpUlEfzOmPfgPO8ifypMnkhD7zMvm581wap8NJgb9YIJxjbVhj9RS9 MLw6NVuGd+MTbLXiGKnRhJ1D/BKQrTZoMy+jKewCQ38mfI8=
X-Google-Smtp-Source: AA+uWPx4euEhNoBZx5wzrmV/iX+hbMmb0M5XQ/v2F0QbMGpvWckd7UDK2VhcOr2yJh2ojLjeYlHJDgWEZZwDN1emzx8=
X-Received: by 2002:a24:6c04:: with SMTP id w4-v6mr14329705itb.4.1534793261891; Mon, 20 Aug 2018 12:27:41 -0700 (PDT)
MIME-Version: 1.0
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 20 Aug 2018 15:27:30 -0400
Message-ID: <CAHbrMsAMMMvAWuLYRgkC6P4p-DvTVvbe69HoMiz14Zp9Km17MQ@mail.gmail.com>
To: Dispatch WG <dispatch@ietf.org>
Cc: Katharine Daly <dalyk@google.com>, Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000003a00840573e2e79f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/Wuy6pr41sVySrfIQVu3TrC6WN3I>
Subject: [dispatch] HTTP, QUIC, proxies, and HELIUM
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 19:27:46 -0000

At the DISPATCH session in Montreal, the chairs suggested reaching out to
this list with a taxonomy of the problems that HELIUM is trying to solve.
Here’s a quick attempt at that. (For more information, see Lucas Pardue’s
“HiNT” draft and slides.)

The starting point is the observation that HTTP/QUIC can forward HTTPS
(with HTTP CONNECT), but cannot forward HTTP/QUIC (because CONNECT is
TCP-only).  The baseline requirement, then, is to enable an HTTP/QUIC
server to forward a QUIC connection.

Although this is the starting use case, it is not the only property that
one might desire.  Some additional goals that we’ve considered include


   extending the supported contents to include WebRTC, DNS, or even
   arbitrary IP

   extending the supported substrates to include HTTP/2 or even HTTP/1.1

   extending the performance goals (beyond merely “functional”) to include
   minimizing setup latency, or even enhancing congestion control performance
   on difficult paths (e.g. high loss, high latency, or variable latency)

HELIUM attempts to cover all of these extended goals, at least to some
extent, which results in an unconventional, extremely flexible design.

Some participants asked for sketches of solutions with reduced scope that
enable a more familiar approach.  Here are a few:


   If we require that the proxied contents are end-to-end congestion
   controlled (e.g. only QUIC is allowed), then the substrate could safely
   disable congestion control (and reliability and flow control) for those
   packets.  This would require some modifications to HTTP/QUIC (creating a
   DTLS-like mode) but would make congestion control stability much easier to

   If we require that contents are plain UDP only (no IP options like DSCP
   or TTL) and exclude support for server-like behavior, then we can use a
   protocol that maps 1:1 with TURN, for familiar semantics.

   If we require that the server has full “raw IP sockets” access, then we
   can remove all mention of UDP and simply define a VPN-type IP tunnel.

In my view, a protocol that solves one of these restricted problems would
still be a worthwhile advance.

Finally, I’ll note that the level of performance achievable with HELIUM’s
current design is not entirely clear, due to the worrying presence of
layered congestion control.  A more ambitious approach to performance
enhancement might allow the proxy to peek into the content’s congestion
control information. This could enable optimizations like retransmission
from the middle (in both directions) in the event of packet loss.

My question to DISPATCH participants is: what would it take for a solution
to be useful to you?