Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS

David Schinazi <dschinazi.ietf@gmail.com> Wed, 24 June 2020 21:36 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075233A11A1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Jun 2020 14:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Level:
X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 7w-T9PFa_JqR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 24 Jun 2020 14:36:51 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963953A0BDE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 24 Jun 2020 14:36:51 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1joD1f-0001gM-0U for ietf-http-wg-dist@listhub.w3.org; Wed, 24 Jun 2020 21:33:47 +0000
Resent-Date: Wed, 24 Jun 2020 21:33:47 +0000
Resent-Message-Id: <E1joD1f-0001gM-0U@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <dschinazi.ietf@gmail.com>) id 1joD1c-0001fa-Hc for ietf-http-wg@listhub.w3.org; Wed, 24 Jun 2020 21:33:44 +0000
Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <dschinazi.ietf@gmail.com>) id 1joD1a-0002Qe-4Y for ietf-http-wg@w3.org; Wed, 24 Jun 2020 21:33:44 +0000
Received: by mail-lj1-x236.google.com with SMTP id y11so4196945ljm.9 for <ietf-http-wg@w3.org>; Wed, 24 Jun 2020 14:33:41 -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=XsrrVaZx5TdIuB+GxjmFdwBoM74JdIkJcenCOz6njZM=; b=sp1HiM6Cxqux5fMb3HL7ssjYJca7eeHVSC0I/L3MS0QcV+ceyiLP6iaxHM02a7TXa8 BkvJOZ/7gSIdgwEKa9IDra22X4myMFXkDKsLtRlitwVp773VheBaFbUqC0fZEFYNTxJr w4bUvwPZ23PHsby689AFedWGieWknXqPHXZENx8no2TowuAWyeX+Y6NvjYn/sx0nJKMT NYFN/Yc6QDeT3jtFkaNvTkPbjAdgAMqKLNg6osR8VljoE0jBDFNTQm2YurRMGP8Dkx4M veNvbUsHXIthkkjsgetdiWMeb/Hx9HvVaC8KPDWi/UGzMmPG2Mz8mLWh7guMSbJPrlNU VL6g==
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=XsrrVaZx5TdIuB+GxjmFdwBoM74JdIkJcenCOz6njZM=; b=RSk+oKmIzBvVph0ZQEVJ9C4mcQmrym3oJ14hVVN/+2ZYKWF356fPHOTg2kK45hWxFt 5GaKHdGLGizXH2IcBTbTYW2o/Ydgy/mBW9aovgqmM0U72/D6C7A/8KggtcCjZEa3TOjd FlFH/ZL0+m/32pKFM8/K9VmZKyOkhoiff1KyflUgPNacKWo90vRZn0XJcgL1jnc8bybE U5NV7FPWKAHws40SRRNcxT33e71+argXLiteR8q0tO6dwRQHO3CcufnYA6AxOvzw9N7C eIDTyqyKT4fL0NiJNVBATimRZ4ZcYu3bMs4MeUW/mEc3Jl1iIjgvb0p27qdskXHTdpGv Vdqg==
X-Gm-Message-State: AOAM532JAkYRHE+GLg3pxmU0duVFTb0kWlm6DXW2RC8lWmz23sf5w29g yXhRbUHgphR6UqNyYH8noLH9rT98LsDM6l9VL8Y=
X-Google-Smtp-Source: ABdhPJybNbUXPtsdaYbLkHa/+FGPbmnFh/S7KXc6I68RMUwr00SqG3DYV6avaAJn8bhZwzTM/yOnCjPGZhXvAcc8du0=
X-Received: by 2002:a05:651c:550:: with SMTP id q16mr15060967ljp.188.1593034410266; Wed, 24 Jun 2020 14:33:30 -0700 (PDT)
MIME-Version: 1.0
References: <54E08031-1892-4CC0-A6CF-0CAA4BFF679B@mnot.net> <02858E1D-C010-4404-ADF3-5EB97D4B32B3@mnot.net> <CAHbrMsAjuNPcytNHicCUs4-rR2TESNFwGNOX9Pu+xHbEVx0L5A@mail.gmail.com>
In-Reply-To: <CAHbrMsAjuNPcytNHicCUs4-rR2TESNFwGNOX9Pu+xHbEVx0L5A@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 24 Jun 2020 14:33:19 -0700
Message-ID: <CAPDSy+54b3LbHE-+Kodh_xWNNvQtMi=rcw4iwBz8yskT=6CtsQ@mail.gmail.com>
To: Ben Schwartz <bemasc@google.com>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000023924605a8db3aa7"
Received-SPF: pass client-ip=2a00:1450:4864:20::236; envelope-from=dschinazi.ietf@gmail.com; helo=mail-lj1-x236.google.com
X-W3C-Hub-Spam-Status: No, score=-5.1
X-W3C-Hub-Spam-Report: 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1joD1a-0002Qe-4Y 6f509edb78618eb8fb67dbdda386fab8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <https://www.w3.org/mid/CAPDSy+54b3LbHE-+Kodh_xWNNvQtMi=rcw4iwBz8yskT=6CtsQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37820
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Thanks for bringing this up, Mark!

The split between draft-schinazi-quic-h3-datagram
and draft-schinazi-masque-connect-udp mainly came from my intuition at the
time, and is definitely something we could change. The rationale at the
time was that there might be some applications that are interested in using
datagrams over an h3 connection, but not associating those with HTTP
semantics. After conversations with Mark, I'm no longer sure that these are
necessarily useful.

CONNECT-UDP has the nice property of fitting in with HTTP semantics and
being able to work across multiple HTTP hops. One possible solution could
be to fold draft-schinazi-quic-h3-datagram
into draft-schinazi-masque-connect-udp, and then have the combined document
tie QUIC DATAGRAM frames over an HTTP/3 connection with a given CONNECT-UDP
stream. My main concern is that if we come up with a new HTTP mechanism
that would like to use datagrams but couldn't be solved by extending
CONNECT-UDP, then we'd be in a bind because it might be impossible to use
both CONNECT-UDP and this new mechanism over the same connection. Another
solution could be to keep the drafts separate, and
have draft-schinazi-quic-h3-datagram mention that any application that uses
it MUST define associated HTTP semantics and how datagrams work across
multiple HTTP hops.

@Ben I don't think reusing extended CONNECT is an option for CONNECT-UDP,
because of backwards compatibility: if a proxy were to receive a CONNECT
request with ":protocol" set to "udp", it might ignore the ":protocol"
header and create a TCP connection to the host and port instead of UDP. I
think it's important that CONNECT-UDP to a non-supporting proxy fail
instead of fallback to TCP.

David

On Wed, Jun 24, 2020 at 11:30 AM Ben Schwartz <bemasc@google.com> wrote:

> One direction I think could be interesting is to embrace the Extended
> CONNECT as used by WebSocket-H2 (RFC 8441).  If we define ":protocol = tcp"
> as a synonym for the old-fashioned CONNECT, then ":protocol = udp" could
> represent the basic MASQUE case nicely, and ":protocol = webtransport"
> might go naturally as well (if we can't reuse ":protocol = websocket").
>
> The combination of :protocol and transport (H3 vs. H2) might be sufficient
> to indicate whether datagrams are allowed.
>
>
>
> On Tue, Jun 23, 2020 at 4:49 AM Mark Nottingham <mnot@mnot.net> wrote:
>
>> My personal .02 on this (and I'd be very curious to hear others'
>> reactions) --
>>
>> We don't have a good track record of creating extensions or new
>> capabilities that don't map into HTTP semantics. Server Push is probably
>> the poster child here. As such, creating a version-specific extension for
>> DATAGRAMs without mapping them into a method (or whatever) seems like it's
>> leaving an attractive nuisance around; how will it show up in APIs? How
>> will it interact with intermediaries? Etc.
>>
>> We also don't have a lot of precedent for a HTTP version-specific
>> extension that does something completely separate to the HTTP interaction
>> that's happening on the connection. I'm not sure that it would be something
>> we want to encourage.
>>
>> All that said, we're not the protocol police; I don't think we should
>> _stop_ this, but I do think that if we want this to succeed, it might work
>> better as something packaged together with CONNECT-UDP (or however it gets
>> expressed in HTTP).
>>
>> AIUI the one big argument for factoring it out into a separate draft is
>> that MASQUE might want to use it *without* a method (etc.) for IP proxying.
>> So that might be a conversation to have (although that use case has been
>> delayed, I think).
>>
>> Another potential consumer could be a header on CONNECT (or even other
>> methods?) that allows unreliable delivery but degrades gracefully to
>> reliable delivery on hops that don't provide it. Even then, it seems like
>> such a spec could reference the wire formats, etc., in CONNECT-UDP once
>> that's defined.
>>
>> Overall - I have a preference for this to be rolled into a CONNECT-UDP
>> (or similar) spec, but can live with it as a separate doc, provided that
>> some thought is put into warning potential users about some risks.
>>
>> What do other folks think?
>>
>>
>> > On 23 Jun 2020, at 9:40 am, Mark Nottingham <mnot@mnot.net> wrote:
>> >
>> > Hi all,
>> >
>> > The new MASQUE[1] and WEBTRANS[2] working groups both wish to define
>> new protocols using QUIC DATAGRAM frames[3] that are not conveying
>> (existing) HTTP semantics, but are intended to be usable over (at least
>> some versions of) a HTTP connection.
>> >
>> > MASQUE's purpose is to proxy UDP and potentially IP (like a VPN) over a
>> HTTP/3 connection. For WEBTRANS, the purpose is to create a
>> browser-exposed, WebSocket-like protocol that allows unreliable delivery
>> (which may also use CONNECT-UDP). These summaries are just my
>> understanding; for a more complete picture, see the respective charters and
>> related WG discussion.
>> >
>> > It's not yet clear how or even if these protocols will map into HTTP
>> semantics. Some have proposed something like a CONNECT-UDP method; others
>> seem to favour negotiating a new protocol using SETTINGS or a similar
>> version-specific mechanism directly, avoiding the definition of any generic
>> HTTP semantics.
>> >
>> > So far, the most concrete proposal we have is
>> draft-schinazi-quic-h3-datagram,[4] which defines how QUIC DATAGRAM frames
>> are surfaced in HTTP/3 without any mapping them into generic HTTP semantics
>> (like a method, status code, header, etc.). Thus, a specification using
>> them has the choice of defining a generic HTTP extension (like CONNECT-UDP,
>> mapping them into HTTP semantics) or a version-specific extension(like
>> SETTINGS, bypassing generic semantics).
>> >
>> > Before these groups get too far down the road, we have an opportunity
>> to give them some guidance about how to extend both HTTP's semantics
>> overall, and specific versions of HTTP -- keeping in mind recent core
>> discussions.[5]
>> >
>> > The most relevant question is whether new, non-HTTP protocols on a HTTP
>> connection should be bootstrapped by generic HTTP semantics (e.g., a
>> method), version-specific semantics (e.g., SETTINGS), or something else.
>> >
>> > There's also a question as to whether something like
>> draft-schinazi-h3-datagram is the right approach, or whether it should also
>> include generic HTTP semantics "bundled in."
>> >
>> > Do folks have any thoughts about this?
>> >
>> > Cheers,
>> >
>> >
>> > 1. <https://datatracker.ietf.org/wg/masque/about/>.
>> > 2. <https://datatracker.ietf.org/wg/webtrans/about/>.
>> > 3. 'An Unreliable Datagram Extension to QUIC', <
>> https://tools.ietf.org/html/draft-ietf-quic-datagram>gt;.
>> > 4. <https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram>.
>> > 5. <https://github.com/httpwg/http-core/issues/44>.
>> >
>> > --
>> > Mark Nottingham   https://www.mnot.net/
>> >
>> >
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>
>>