Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 25 June 2020 19:07 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 7434E3A0FD3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Jun 2020 12:07:23 -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 oGfEb9ZfVSKg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Jun 2020 12:07:21 -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 44C053A0FD4 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Jun 2020 12:07:20 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1joXAi-0008QQ-EA for ietf-http-wg-dist@listhub.w3.org; Thu, 25 Jun 2020 19:04:28 +0000
Resent-Date: Thu, 25 Jun 2020 19:04:28 +0000
Resent-Message-Id: <E1joXAi-0008QQ-EA@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1joXAf-0008Pe-N5 for ietf-http-wg@listhub.w3.org; Thu, 25 Jun 2020 19:04:25 +0000
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <lucaspardue.24.7@gmail.com>) id 1joXAd-0004HD-Dj for ietf-http-wg@w3.org; Thu, 25 Jun 2020 19:04:25 +0000
Received: by mail-wm1-x32d.google.com with SMTP id t194so7043508wmt.4 for <ietf-http-wg@w3.org>; Thu, 25 Jun 2020 12:04:23 -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=txxUq7llHMSLwrnBRSsd3aDIey3RWf8gloYLeu9PwEY=; b=kJvT/RzIWtw4zmKxqyWrad5hUj6flMMgRbRXOxBOVvwoyrBCi4+ePl3YlJDzN1xKVn Ubm/FlH1XiohCAAtoa6+f5Ne10UKtzQLzyg77tQ7RTFX7LZwAjObc1Bhiw4BAoRQMeGg ZIaGghNnLkBA2jHqEUTv0/mHgk1ivz3Yawehq3UbW55VqcfJ90JcSNkCO4yfpsVZNwG3 /+6yi/unebu/tij0r56vu3fpxC+fPoERiFnpqQgZDEo8PrKT5Mgtw4x8JztgbLGTjxVV CnlQyvtiqOt6FU68/gTLBYkYCwC+4IM4x0RunEonWGk8MO+BgGOHV5/o0dflHcBIdx7k 804w==
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=txxUq7llHMSLwrnBRSsd3aDIey3RWf8gloYLeu9PwEY=; b=SxEisN/FKTcTJcyXDKWiXVgFABBfvKtjAQGpuhReQLANvG9W4208JWBsiVsP2YKvFJ Gi2OUmnkioCwjgtQBSgD2xROXSNsS4qTEvpv2gOGKwm9WScDOv+xl1U33ERksrIukc0U Xqnz21U0G8U7szcTslhx2JhEqKKAx5MUQLnsnF9d3HekClOFMhZWCCU2YZbhXjihtfiU gCEF2Pv3+qgcjLwH/4BPflXz1JVgC1mqrvIdBkSyacrn4rsmtDRNUoKyL8dpl0UUASMm agCamkNX4pIf57tqixoz167z1z09gQ2LFZxOGIdDsYPEdV/UKgp3lcWcBnocNypyEAvN w90w==
X-Gm-Message-State: AOAM531VEdBTGdgBP774uvzR2mSpmf5Q4ItFeqDDinOVrJ7PiWHxx4G/ zA6X4jztXCaDCTtbfkJnG04kdQRH5Eg369fd3dA=
X-Google-Smtp-Source: ABdhPJyF7p0lUAhCVuejUsTCrx3bcpu6AQtVkPrSdJEO2/IkbxxO/S1g8txd+a7w+j4hMvEwir30K86HHKaxHt6uiBM=
X-Received: by 2002:a7b:cb98:: with SMTP id m24mr5002240wmi.98.1593111851577; Thu, 25 Jun 2020 12:04:11 -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> <CAPDSy+54b3LbHE-+Kodh_xWNNvQtMi=rcw4iwBz8yskT=6CtsQ@mail.gmail.com> <CAHbrMsCThXrqqhjr8A3PkSZ3Lqs8TL6R+yzD89FLfuEN2cKNcA@mail.gmail.com> <E47B4709-C61B-4452-8BCE-FCB0B8C58EBA@apple.com>
In-Reply-To: <E47B4709-C61B-4452-8BCE-FCB0B8C58EBA@apple.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 25 Jun 2020 20:04:00 +0100
Message-ID: <CALGR9oZO-FdZouCWkfrnKoATARS6HWBUkCtyS63MG+FGPxB-CA@mail.gmail.com>
To: Eric Kinnear <ekinnear@apple.com>
Cc: Ben Schwartz <bemasc@google.com>, David Schinazi <dschinazi.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000000363b05a8ed42d5"
Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=lucaspardue.24.7@gmail.com; helo=mail-wm1-x32d.google.com
X-W3C-Hub-Spam-Status: No, score=-7.8
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_ENVFROM_END_DIGIT=0.25, 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_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1joXAd-0004HD-Dj 00d66dc6adfa0489f68d6891a0c26612
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/CALGR9oZO-FdZouCWkfrnKoATARS6HWBUkCtyS63MG+FGPxB-CA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37827
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>
Lots a food for thought in this thread, I'll pick on one aspect for now: On Thu, Jun 25, 2020 at 2:52 AM Eric Kinnear <ekinnear@apple.com> wrote: > I know that one of the reasons to split out into H3 datagrams was to have > a flow ID present to allow multiple different flows of data to coexist, and > there was quite lively discussion at the time which was fairly split as to > the utility vs. dangers of such flow IDs. > > The biggest questions in my mind in that area are: How much do we care > about sharing an HTTP connection that is using HTTP semantics on some > streams with these other frames? And does that, in turn, mean that we need > to define HTTP semantics for the datagrams (H3 or H2 or otherwise)? > > My personal gut reaction would be (a) yes, we do care and (b) probably not > necessary as long as we can correctly demux what information is intended > for what extension/protocol living at the other end. > Over on the datagram spec repo [1] we are still discussing the topic of flow IDs. From that I've been more deeply considering my implementation of QUIC DATAGRAM and looking ahead to HTTP/3 DATAGRAM, especially how that layering would work and the API presented by the layers*. So, devil's advocate, I'm wondering why we need the abstract notion of a flow ID in HTTP/3 - draft-schinazi-quic-h3-datagram-03 [2] defines the requirement "Implementations of HTTP/3 that support the DATAGRAM extension MUST provide a flow identifier allocation service.", which as a library implementer I struggle to satisfy. It also offers little guidance on things like security considerations or DoS analysis, which is really where a common definition would help because it would force the issue of determining if we need to communicate things such as limiting the number of total concurrent flows, how to retire a flow etc, how to report limit violations/error, how to gracefully close an HTTP/3 connection with active flows etc. The closest parallel for me is HTTP/3's management of server push via push ID, it fixes an accounting loophole that exists in HTTP/2 and provides explicit guidance for use with GOAWAY. If HTTP/3 DATAGRAM were to stay generic then IMO it needs to think about some factors like that. However, if the use of DATAGRAMs is always required to be defined alongside by an HTTP semantic then it might be able to play by the rules of that semantic; for example, consider that we define a tight binding between DATAGRAM and CONNECT-UDP - an implementation could apply the security considerations and resource management that it already does for HTTP requests. Thus the number of concurrent flows is bound by the number of concurrent requests and flow ID fate fate is tied to request ID fate, which is tied to connection fate. Furthermore it would support the carriage of per-flow limits expressed as headers. So to address the OP, I think we need to fully consider semantics up front: either true version-independent HTTP semantics or, as the QUIC charter likes to call them version-specific semantics. The danger is not doing so is that people start deploying things that we have to retroactively attempt to describe e.g. "A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request" Cheers, Lucas * in quiche, we present both QUIC and HTTP/3 API layers and document how applications are expected to use them when using one or both of the layers. [1] - https://github.com/quicwg/datagram/issues/6 [2] https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram-03
- HTTP extensions, semantics and HTTP datagrams / M… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Ben Schwartz
- Re: HTTP extensions, semantics and HTTP datagrams… David Schinazi
- Re: HTTP extensions, semantics and HTTP datagrams… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Ben Schwartz
- Re: HTTP extensions, semantics and HTTP datagrams… Eric Kinnear
- Re: HTTP extensions, semantics and HTTP datagrams… Lucas Pardue