From nobody Fri Jul 10 08:56:13 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575A83A115C for ; Fri, 10 Jul 2020 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 Gsqxqmo7KfuZ for ; Fri, 10 Jul 2020 08:56:02 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 5DBEB3A0FE0 for ; Fri, 10 Jul 2020 08:55:30 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id j11so7016393ljo.7 for ; Fri, 10 Jul 2020 08:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=f8cQFkXlECEqF1giVg7G8ah1/1jkK8zbfhDxpYSNuek=; b=MZ/wzYdSWrR134KIkdL6H8psF2Zyf8mqHRJqU7VWFprNrD+HAGwk6nqbww67reW9Q2 JXw0kfhuXu0L1+2WCCBFyGR65aC3HP61v/YLALmNzxgYX8bXGFpA0B+IJh4gY8wY8txU kU4EvK6dg/rwHleLGw1dzrBcDvYPPPVJ4OwoLamTVWBnYpM+zT8v68y3fZ9z6grOMd88 cTM4FWuXUi1H1Tt+mclExilzjtJjx7Lakt1TbQlAOyLvHFSp6c9Zv3Ew1acHhrAMFg1m IDfRduENjlKb1nuVfXxjZB2/RbviuVoELAdT0DGR14wgovlZ8kPQERGcfznkDqYBaTNi +TDQ== 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; bh=f8cQFkXlECEqF1giVg7G8ah1/1jkK8zbfhDxpYSNuek=; b=ambloIhSWt5/C+w0a35ID8zyIBXGSd1B7+GzlEZdNB9k8KTjnIlvInRYprUVUZzfLy 0YYywUxwA4q+htYSAskbwNoeQNyMn7IEi61pMRnHjtklViliV4bfKKWIuRYOHTLT1k7h 9lLIY6cGhMrrvFmzidDj19PIpuQNBU9Jceh5OCgYy1X8vX7J9WJ2pDjcYljipN9JSaxc quOARjEs0irRFOKDzm8g8AbPMN8/ucKPDyHv36g4OJLAbIbmZZVwmu+F9VYt7BVkxRyx JLjSpgeeDUj1z0iEZlcwWYcexRsUHi01ReXKERf8zETHJ66GndJpRAuNkj1X4wCiO8Bb drjQ== X-Gm-Message-State: AOAM531UPWH7PLz6sWlElPC59PkdKUpQ941cX9SdBGbFGyiA7BZhFsX6 qeKWLrAcEMveQjwH40xnXGJcsNFrt0r1t8YXDslLmZn0fs0= X-Google-Smtp-Source: ABdhPJwD7CV/HsR/70yFhwetlqpp7quoXjryi/3mCNE3iTgAZ1V6Ze0Uyu2VwC0ACy/EvZEORM2k/cjVar6uyXVFqro= X-Received: by 2002:a2e:574b:: with SMTP id r11mr29354673ljd.417.1594396528025; Fri, 10 Jul 2020 08:55:28 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Fri, 10 Jul 2020 08:55:17 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000af265c05aa185e5d" Archived-At: Subject: [Webtransport] IETF 108 X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 15:56:12 -0000 --000000000000af265c05aa185e5d Content-Type: text/plain; charset="UTF-8" Here is a summary of the plan for IETF 108. WEBTRANS WG will be sponsoring a "table" at the Hackathon, which begins on Monday, July 20. With QuicTransport in Origin Trial in Chromium, and aioquic support both reliable streams and datagrams, the tools are now available to gain experience with the WebTransport API and the QuicTransport protocol proposal. Here is a link to the QuicTransport Origin Trial documentation: https://web.dev/quictransport/ An example is hosted here: https://webrtc.internaut.com/quic/trial.html (requires a recent build of Chrome or Edge Canary). The WEBTRANS WG will be meeting on Monday, July 27, 2020 for a 100 minute session beginning at 14:10 UTC. If you'd like time on the Agenda, please send email to the Chairs. A reminder that the draft submission deadline for IETF 108 is July 13, 2020 at UTC 23:59. --000000000000af265c05aa185e5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is a summary of the plan for IETF 108.=C2=A0

WEBTRANS WG will be sponsoring a "table" at= the Hackathon, which begins on Monday, July=C2=A0 20.=C2=A0 With QuicTrans= port in Origin Trial in Chromium, and aioquic support both reliable streams= and datagrams, the tools are now available to gain experience with the Web= Transport API and the QuicTransport protocol proposal.=C2=A0 Here is a link= to the QuicTransport Origin Trial documentation:
<= div>
--000000000000af265c05aa185e5d-- From nobody Fri Jul 10 13:15:13 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7435D3A0911 for ; Fri, 10 Jul 2020 13:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 Pw7kk9-rpDCU for ; Fri, 10 Jul 2020 13:15:06 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 1D9D53A0901 for ; Fri, 10 Jul 2020 13:15:06 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id j11so7815639ljo.7 for ; Fri, 10 Jul 2020 13:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hmpBZfB7d13AR0mUFsQNdkPf1OZnNtwlBhvJiE5XVEE=; b=qNDNxAbSap5J6bHyYQ2xf3uzmS+bFQth1weXb2MNh6ycrGhgQgeZN71YNEezmAv6Wa c7IhgTJSAsapmWJSR9/sRjLfjPrRYqU4uIKOc1A6HQT/Zpr93TvOw/mTzQiS+naf5g0t Qy/YdyKIkAQ3ExesxAMTimKYtJITvudvpGbxjYj0cnAD7WP8Hh33aWBLwMJCf1SbqAn5 Y/MXiY78aZuaoAwfaH1CF1hMjfrt7xt1KCB2kG+zXafUOzk6ELZoZtUvmRJg0bzYYwKl 3/hw6rLDghjVpz2Q13EE3NEtTf9OT4Tq1t1onkVBR1Bw37c24CxnXMO1bR0JnJllFwts xNDQ== 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; bh=hmpBZfB7d13AR0mUFsQNdkPf1OZnNtwlBhvJiE5XVEE=; b=mmIrQmsGlb83y5teBmQJeeOUuttQkfOXeAHw9BTnUjFBDs8FEMpX4SPGalUnkj8ce7 ir53DcX6VFniV2aJDHbFmQsYxiX6aVyXNvu5TjTEFiQ7rSrLdOBPs6xVfI7x2j3CFpgk 5IrJxfWpBAaqaQ/I0O/32I4CPgTJmL1SeHP8cYxjVUp98vNSckrbYcNMIRYGAiOM7l70 K04UKeAh/bcOB8eBLxR8lSuT4Q9uz3gi0/G1FAPGOxlnSCCyVxA2W50SlWrM/e3c0BWb hQQjDguj5s9oM6HsoHBdW80LzYX2nGtx48nCXNwvBSqyOG9wQ2yUBaVl4MQ9Bk3NlgW/ s8Bg== X-Gm-Message-State: AOAM531FGzxtgGj6w8WVOeCa0G1xsinQOBkNaHduHDQcWxZtR4bngYZo KdRcNYMKCeOBSG9M4KftI3cayFdAl5qVRb4+Bxr2MWWD X-Google-Smtp-Source: ABdhPJydqNBb8/uXd4HkAV8A/IL205Lca5/c6+pbeR9gK6d26GobCPHUAnNCvq0hGbzPsm5qNYs6J6U/VlAsIply1jU= X-Received: by 2002:a2e:89cc:: with SMTP id c12mr20330988ljk.187.1594412103818; Fri, 10 Jul 2020 13:15:03 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Fri, 10 Jul 2020 13:14:53 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="00000000000012e38705aa1bffa2" Archived-At: Subject: [Webtransport] Preliminary Agenda for IETF 108 X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 20:15:11 -0000 --00000000000012e38705aa1bffa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is a preliminary agenda for IETF 108. If you'd like to get on/off the agenda, or if you want to adjust the time allocation, send email to the chairs. IETF 108 WEBTRANS WG Agenda Monday, July 27, 2020 14:10 - 15:50 UTC 7:10 - 8:50 AM Pacific Time Virtual Room 1 Chairs: Bernard Aboba and David Schinazi 14:10 =E2=80=93 14:30 Preliminaries, Chairs (20 minutes) Note Well Virtual Bluesheets Jabber Scribe, Etherpad Note Takers Speaking Queue Manager (David Schinazi) Agenda Bash W3C WebTransport Update 14:30 - 14:50 WebTransport Overview and Requirements, Victor Vasiliev (20 minutes) https://tools.ietf.org/html/draft-vvv-webtransport-overview 14:50 - 15:05 WebTransport using HTTP/2, Eric Kinnear (15 minutes) https://tools.ietf.org/html/draft-kinnear-webtransport-http2 15:05 - 15:20 WebTransport over QUIC, Victor Vasiliev (15 minutes) https://tools.ietf.org/html/draft-vvv-webtransport-quic 15:20 - 15:35 WebTransport over HTTP/3, Victor Vasiliev (15 minutes) https://tools.ietf.org/html/draft-vvv-webtransport-http3 15:35 - 15:50 Wrap up and Summary, Chairs & ADs (15 minutes) --00000000000012e38705aa1bffa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is a preliminary agenda for IETF 108= .=C2=A0 If you'd like to get on/off the agenda, or if you want to adjus= t the time allocation, send email to the chairs.

I= ETF 108 WEBTRANS WG Agenda

= =C2=A0=C2= =A0

Monday, July 27, 2020

14:10 - 15= :50 UTC

7:10 - 8:50 AM Pacific Time

Virtual= Room 1

Chairs: Bernard Aboba and David Schinazi

=


14:10 =E2=80=93 14:30 Preliminar= ies, Chairs (20 minutes)

=C2=A0=C2=A0 Note Wel= l

=C2=A0=C2=A0 Virtual Bluesheets

=C2=A0=C2=A0 Jabber Scribe, Etherpad Note Takers

=C2=A0=C2=A0 Speaking Queue Manager (David Schinazi)

=C2=A0=C2=A0 Agenda Bash

= =C2=A0=C2=A0 W3C WebTransport Update


14:30 - 14:50 WebTransport Overview and Requirements,= Victor Vasiliev (20 minutes)

https://tool= s.ietf.org/html/draft-vvv-webtransport-overview


14:50 - 15:05 WebTransport using HTTP/2, Eric= Kinnear (15 minutes)

https://tools.ietf.or= g/html/draft-kinnear-webtransport-http2


15:05 - 15:20 WebTransport over QUIC, Victor Vasiliev= (15 minutes)

https://tools.ietf.org/html/draft-= vvv-webtransport-quic

<= span style=3D"font-variant-ligatures:no-common-ligatures">

15:20 - 15:35 WebTransport over HTTP/3, Victor Vasiliev (15 minutes)

https://tools.ietf.org/html/draft-vvv-webtranspor= t-http3


15:35 - 15= :50 Wrap up and Summary, Chairs & ADs (15 minutes)

--00000000000012e38705aa1bffa2-- From nobody Thu Jul 16 12:26:19 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4493A0B39; Thu, 16 Jul 2020 12:26:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: webtransport@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159492757534.14301.11280275768909895166@ietfa.amsl.com> Date: Thu, 16 Jul 2020 12:26:15 -0700 Archived-At: Subject: [Webtransport] webtrans - Requested sessions have been scheduled for IETF 108 X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 19:26:16 -0000 Dear Bernard Aboba, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. webtrans Session 1 (1:40 requested) Monday, 27 July 2020, Session III 1410-1550 Room Name: Room 1 size: 1 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/webtrans.ics Request Information: --------------------------------------------------------- Working Group Name: WebTransport Area Name: Applications and Real-Time Area Session Requester: Bernard Aboba Number of Sessions: 2 Length of Session(s): 100 Minutes, 100 Minutes Number of Attendees: 130 Conflicts to Avoid: Chair Conflict: avtcore avtcore dnssd dnssd mmusic mmusic artarea artarea dispatch dispatch Technology Overlap: quic quic httpbis httpbis masque masque ript ript tls tls People who must be present: Bernard Aboba Bernard Aboba Barry Leiba Barry Leiba David Schinazi David Schinazi Resources Requested: Special Requests: Since the key WG participants are on the us west coast, a meeting time friendly to that time zone would be appreciated (e.g. between the hours of 8 AM and midnight). --------------------------------------------------------- From nobody Wed Jul 22 14:23:34 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D9F3A09D7 for ; Wed, 22 Jul 2020 14:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7ZirKpq2s4M for ; Wed, 22 Jul 2020 14:23:31 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 3F3813A09D1 for ; Wed, 22 Jul 2020 14:23:31 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id s9so4050794ljm.11 for ; Wed, 22 Jul 2020 14:23:31 -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; bh=6Rrj7rLCqDH8kfJOQSZYV2gCxySKXIv1e4nKQmqZXqk=; b=d6YJdplyJ1wOvjDemz+9qPC97wOlPOqaDGPhAe/eRFdaNgnbziK4RmFbhJMs1p7+21 8z6JhlEChvZCUJIu4Fg/tNMOCH2vCf8nUXv8D53bPe6eC3TLh8LVK+Dw4YP0xfm9ym2M qLUUnGkHLWmD/J6qulI4RbYDP651em3C+eX1qklpAa6BJVv5t2VXYi+OrD0ZVRQA9lFF wmTBLXyconthG2bbDXETqVm3gyUc1K26wa7Ej5Ax+edVvaBolhg39/nKX1n/qPaA6Rw4 GoBi7OslNY8MqNFZJPUEXMrv/F1KnB74R2r6IlAQDr7p/9/HLuh9oDZ3QG/NzN5lDWw+ TPmA== 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; bh=6Rrj7rLCqDH8kfJOQSZYV2gCxySKXIv1e4nKQmqZXqk=; b=uXCCOENhgG3svODBxS07w5DYi2UnstUAsu4bOBxqemGIwmmW5fxO2nzQCRytPRgwxg wSwdA9khD40muzSe1h8hpIsxCe/GjGa/TbUgxf5gtK+PlvhadekXJEUFAhNkU0UFKbVy Jjpp/darFpRffvDLuzc1DjpIbwHT9AEEX8V2YAoith+R72E7raF7HVtB8zLH3hFpM1GE y2pXLIZMGZWflNldOYagDMxW7SipXaRMZ7nhUzHhLthnng3HfVUVj9qZKSGLGxX/HNvG U47obBf8nwSUkoXyxsVNQao7yeOE84Y9uxFsVFZ0CPy4keIqqEfTZiQFp0MqYN/i5ywz +hbw== X-Gm-Message-State: AOAM532L929bJIp1aSMFhEN0cdXW3LsPAqQ7GAxBtyLdSIQ8gDULF8h7 VDjxq+xGwz7plgvFB71IUkh5EtMMPwfNTFkyG9RyiZX/0ww= X-Google-Smtp-Source: ABdhPJwHdg5sFkEOXkitmmw26AHAe/IeRcFzb40Tz69F4GBctU1ilE3MIEA/Lv7E6kYbHhOaOMSu27Pac+jmqDuDoq8= X-Received: by 2002:a2e:81c4:: with SMTP id s4mr533600ljg.284.1595453008680; Wed, 22 Jul 2020 14:23:28 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Wed, 22 Jul 2020 17:23:17 -0400 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000d6ecbc05ab0e597b" Archived-At: Subject: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 21:23:34 -0000 --000000000000d6ecbc05ab0e597b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, We recently adopted the overview draft that describes the general requirements for and the model of WebTransport. However, we haven't yet adopted any specific wire protocol proposals. There are currently three of those presented to the working group: - QuicTransport - Http2Transport - Http3Transport - [hypothetical WebTransport over WebSocket] Back when the original idea of WebTransport was forming, the hope was to implement and ship all four of those, since they all fit different use cases better. After talking more to the people at IETF, it sounds like four transports is a bit too much, and we should settle on two (one over QUIC, and one over TCP). The natural picks would be either Http3Transport with Http2Transport as fallback (HttpTransport for short), or QuicTransport with=E2=80=A6 *something* as a fallback. Let=E2=80=99s look at the differe= nces between those two options. *Differences* The most substantial wire format difference between those two proposals is the handshake. QuicTransport originally did not have any handshake; we had to add a bespoke handshake later in order to implement the Origin header, and we also added a Path header later on. We currently don=E2=80=99t have = any form of response headers, so if the server is unhappy with the origin or path received, it has to close the connection with CONNECTION_CLOSE. In HttpTransport, we have regular HTTP header fields for both request and response, meaning that the server can do things like return a 4xx/5xx for an error. During the connection itself, the difference is minimal: QuicTransport uses streams and datagrams as-is, while Http3Transport prefixes everything with an ID, since it is multiplexed with other HTTP traffic. There might be a question of whether prefixing can impose undesirable framing overhead; I think if that ever becomes a serious problem, we can come up with some extension to work this around. If we decide that QuicTransport is a way to go, we=E2=80=99d have to add mo= re features into its handshake, since I suspect most people won=E2=80=99t be h= appy with what=E2=80=99s in there right now (HTTP headers like Location or Forwa= rded would be a good example of what people would end up needing in practice, together with an ability to tag along arbitrary key-value metadata for debugging purposes). If we decide that HttpTransport is a way to go, we would have to ensure that the result is easy for Web developers to use, and that we understand the differences between it and regular HTTP. >From the server complexity standpoint, I am not particularly worried about either. We=E2=80=99ve implemented QuicTransport in Chrome, and I wrote two= servers for it, in C++ and in Python; the Python one took about 100 lines of code. Http2Transport has been implemented, in somewhat different forms, by both Apple and Facebook, so we have practical experience with it too. I was previously concerned that having to implement HPACK/QPACK would be a burden to the Web developers since those are more complex than what you=E2=80=99d typically find in a WebSocket implementation, but now that we have a draft to turn compression off , I=E2=80=99m less w= orried about this. There is a question of how much of the HTTP ecosystem we would be actually getting by adopting HTTP. It is true that basing WebTransport on HTTP does not mean HTTP middleware would automatically implement it. That said, we do get a lot of useful features from HTTP, notably message routing and a well-understood metadata format. Everyone knows what a code 200 or 404 is, and a lot of people have built their internal debugging/tracing tools based on adding HTTP headers to things, and being able to easily port those to WebTransport would be an asset. I=E2=80=99ve seen some arguments that cont= ent negotiation and caching might be applicable to certain classes of WebTransport resources too (e.g. a live stream can be cached in the sense that requesting a live stream is joining it), though those kinds of cases would have to be content-specific and they do not generalize as nicely as caching for regular HTTP resources. An interesting point to note is that WebTransport is always included programmatically (as opposed to being navigated to or sourced via URL from HTML), thus alleviating the need for a lot of otherwise useful HTTP headers. *Questions* While on the surface the question here is =E2=80=9Cwhich drafts should we a= dopt?=E2=80=9D, I would like to break this question down into two layers: 1. Do we want to use the wire format in which we try to build minimally on top of QUIC (QuicTransport), or do we base it on HTTP? 2. To what extent WebTransport connections act like HTTP connections? Do they have https URLs or a dedicated schema? Which HTTP headers do an= d don=E2=80=99t work? Regarding the first issue, I am increasingly leaning towards keeping only the HTTP-based option. QuicTransport=E2=80=99s most appealing feature is it= s simplicity; however, ever since we=E2=80=99ve had to add a header to commun= icate the Web origin, there has been increasingly more and more reasons to add new features to it, so even if we go that way, we=E2=80=99re probably going= to end up with something that=E2=80=99s a lot like HTTP. Also, we know exactly ho= w to do TCP fallback in this case, so this removes a lot of design problems from consideration. Fixing complexity and other problems with HTTP is probably more viable. Regarding the second issue, I am not sure how much of it is in scope for this working group. While we do need to define a URL schema, and the choice of schema will give us a lot of answer (by making WebTransport same or different origin as HTTP), a lot of those questions have been traditionally answered somewhere in Fetch spec, or simply not addressed in the standards at all. I am not quite sure what to do with those. What do people think? --000000000000d6ecbc05ab0e597b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

We recently adopted the overview draft= that describes the general requirements for and the model of WebTransp= ort.=C2=A0 However, we haven't yet adopted any specific wire protocol p= roposals.=C2=A0 There are currently three of those presented to the working= group:
Back = when the original idea of WebTransport was forming, the hope was to impleme= nt and ship all four of those, since they all fit different use cases bette= r.=C2=A0 After talking more to the people at IETF, it sounds like four tran= sports is a bit too much, and we should settle on two (one over QUIC, and o= ne over TCP).=C2=A0 The natural picks would be either Http3Transport with H= ttp2Transport as fallback (HttpTransport for short), or QuicTransport with= =E2=80=A6 something as a fallback.=C2=A0 Let=E2=80=99s look at the d= ifferences between those two options.

Differences

The = most substantial wire format difference between those two proposals is the = handshake.=C2=A0 QuicTransport originally did not have any handshake; we ha= d to add a bespoke handshake later in order to implement the Origin header,= and we also added a Path header later on.=C2=A0 We currently don=E2=80=99t= have any form of response headers, so if the server is unhappy with the or= igin or path received, it has to close the connection with CONNECTION_CLOSE= .=C2=A0 In HttpTransport, we have regular HTTP header fields for both reque= st and response, meaning that the server can do things like return a 4xx/5x= x for an error.

During the connection itself, the difference is mini= mal: QuicTransport uses streams and datagrams as-is, while Http3Transport p= refixes everything with an ID, since it is multiplexed with other HTTP traf= fic.=C2=A0 There might be a question of whether prefixing can impose undesi= rable framing overhead; I think if that ever becomes a serious problem, we = can come up with some extension to work this around.

If we decide th= at QuicTransport is a way to go, we=E2=80=99d have to add more features int= o its handshake, since I suspect most people won=E2=80=99t be happy with wh= at=E2=80=99s in there right now (HTTP headers like Location or Forwarded wo= uld be a good example of what people would end up needing in practice, toge= ther with an ability to tag along arbitrary key-value metadata for debuggin= g purposes).=C2=A0 If we decide that HttpTransport is a way to go, we would= have to ensure that the result is easy for Web developers to use, and that= we understand the differences between it and regular HTTP.

From the= server complexity standpoint, I am not particularly worried about either.= =C2=A0 We=E2=80=99ve implemented QuicTransport in Chrome, and I wrote two s= ervers for it, in C++ and in Python; the Python one took about 100 lines of= code.=C2=A0 Http2Transport has been implemented, in somewhat different for= ms, by both Apple and Facebook, so we have practical experience with it too= .=C2=A0 I was previously concerned that having to implement HPACK/QPACK wou= ld be a burden to the Web developers since those are more complex than what= you=E2=80=99d typically find in a WebSocket implementation, but now that w= e have a = draft to turn compression off, I=E2=80=99m less worried about this.
=
There is a question of how much of the HTTP ecosystem we would be actua= lly getting by adopting HTTP.=C2=A0 It is true that basing WebTransport on = HTTP does not mean HTTP middleware would automatically implement it.=C2=A0 = That said, we do get a lot of useful features from HTTP, notably message ro= uting and a well-understood metadata format.=C2=A0 Everyone knows what a co= de 200 or 404 is, and a lot of people have built their internal debugging/t= racing tools based on adding HTTP headers to things, and being able to easi= ly port those to WebTransport would be an asset.=C2=A0 I=E2=80=99ve seen so= me arguments that content negotiation and caching might be applicable to ce= rtain classes of WebTransport resources too (e.g. a live stream can be cach= ed in the sense that requesting a live stream is joining it), though those = kinds of cases would have to be content-specific and they do not generalize= as nicely as caching for regular HTTP resources.=C2=A0 An interesting poin= t to note is that WebTransport is always included programmatically (as oppo= sed to being navigated to or sourced via URL from HTML), thus alleviating t= he need for a lot of otherwise useful HTTP headers.

Questions=

While on the surface the question here is =E2=80=9Cwhich drafts sho= uld we adopt?=E2=80=9D, I would like to break this question down into two l= ayers:
  1. Do we want to use the wire format in which we try to buil= d minimally on top of QUIC (QuicTransport), or do we base it on HTTP?
    2. <= li>To what extent WebTransport connections act like HTTP connections?=C2=A0= Do they have https URLs or a dedicated schema?=C2=A0 Which HTTP headers do= and don=E2=80=99t work?

Regarding the first issue, I am incre= asingly leaning towards keeping only the HTTP-based option. QuicTransport= =E2=80=99s most appealing feature is its simplicity; however, ever since we= =E2=80=99ve had to add a header to communicate the Web origin, there has be= en increasingly more and more reasons to add new features to it, so even if= we go that way, we=E2=80=99re probably going to end up with something that= =E2=80=99s a lot like HTTP.=C2=A0 Also, we know exactly how to do TCP fallb= ack in this case, so this removes a lot of design problems from considerati= on.=C2=A0 Fixing complexity and other problems with HTTP is probably more v= iable.

Regarding the second issue, I am not sure how much of it is i= n scope for this working group.=C2=A0 While we do need to define a URL sche= ma, and the choice of schema will give us a lot of answer (by making WebTra= nsport same or different origin as HTTP), a lot of those questions have bee= n traditionally answered somewhere in Fetch spec, or simply not addressed i= n the standards at all.=C2=A0 I am not quite sure what to do with those.
What do people think?
--000000000000d6ecbc05ab0e597b-- From nobody Wed Jul 22 20:26:46 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E936A3A0B5D for ; Wed, 22 Jul 2020 20:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 LINq5_HciVMJ for ; Wed, 22 Jul 2020 20:26:43 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 855093A0B5B for ; Wed, 22 Jul 2020 20:26:43 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id f5so4776891ljj.10 for ; Wed, 22 Jul 2020 20:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=w7NWYS7V86NWqXpU/e6kbPc1W8AqkyqXcO7snTVsDiE=; b=lkDDGg1MIUXSm+6sJEMerj/eR/uXe9PhgpHDbqheWsW7WBlMow/i904tmne6N5GtCE YEYC+dEFDIo+xJSW48fhSV8qG+lsvuBuKqChrBkUTPxXZXcjbseAVHsNpBs+wtF7pXSi HlfOKXGayBCabC9ZuPrtBhkv4hFWJunue///ALNTH8r2uEq0D0pL+TY2iKKB8gcZk+l6 9OosXTOum1orpgIh3bSdfYLh03mCk1tvYj6rmNNtEbnCByCnV7U8NsduMdgtejYhjTuf HTiij3fyjkwn1bRKwia7vBVNx7EFpWDaVV42gHX04+T6kayCfXrtO/2IDnmZsAJo4GG5 KykQ== 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; bh=w7NWYS7V86NWqXpU/e6kbPc1W8AqkyqXcO7snTVsDiE=; b=IqRa+P0yjiK1PxwprPKIoCuD4T3FdcjzJfurZjmDt6mR3KhddQiVEXVG4iNk/G+ngn dqxWrK2BgdGNCpjEbTKz1ry3uLRAaJtaVg33tECe1y3wb7ezq/sE3gL0OwvRXiOGyFKv oHdlhzqrQQl0e0QzWFuOUcwteRZfDWR39peA8IAtK5PUSku8aWzNCqdQK7ViiRuad2HX xMQ0SYL90so/b0tu3NEdVquiPNq5wA7vZ8XY5uMsC9J+xj2gFaMjywKWypp8BML0gDQV keSlyVMVgU6TRtcd/l39kwT9QYUmhtCRvuqQAIP0PAEInnneTRdxLQIiheEaXnEQ13pi /xbg== X-Gm-Message-State: AOAM532+ogRSoHI6hiJBv+ytRd2ghFAEQ54N/RGzABurPWWOi830Kh7T na60sWPF90vtk3TJfxfwhrlOF/BivvOzzGUemGXCK5tRPfM= X-Google-Smtp-Source: ABdhPJxdiN2RWZXiPncoJa3aAZL7b2fq0oCcMVKsRmrUjEBasBXAqW/ulSyoKKJPaWrE5oCdy6Ig4SM5Z2UcBSyLd5w= X-Received: by 2002:a2e:8157:: with SMTP id t23mr1022393ljg.417.1595474800995; Wed, 22 Jul 2020 20:26:40 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Wed, 22 Jul 2020 20:26:29 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000c2f1f805ab136ccb" Archived-At: Subject: [Webtransport] Use Cases (was Choosing the transport) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 03:26:45 -0000 --000000000000c2f1f805ab136ccb Content-Type: text/plain; charset="UTF-8" Victor said: ""Back when the original idea of WebTransport was forming, the hope was to implement and ship all four of those, since they all fit different use cases better. After talking more to the people at IETF, it sounds like four transports is a bit too much, and we should settle on two (one over QUIC, and one over TCP)." [BA] This is a good question to ask, given some of the sentiments toward simplicity that were expressed at IETF 107 as well as IETF 106. However, since the four proposals "all fit different use cases better", it would seem hard to answer the question without reference to the use cases. The WEBTRANS WG Charter envisaged use cases as being developed along with the requirements: "To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort." Since the current Overview Document doesn't include use cases, at this point, the best list we have is the one presented at IETF 106 (slide 12): - Machine learning - Web games - Live streaming - Cloud gaming - Remote desktop - Web chat The division of these use cases between QuicTransport and Http3/Http2 transport is not stated on Slide 12, but on slide 15, the following use cases were indicated as suitable for QuicTransport: - Video games on the Web - Real-time media Can we assume that "Video games" corresponds to the "Cloud Gaming" use case, but perhaps not the "Web games" use case? Does "realtime media" correspond to the "machine learning" or "live streaming" use cases, or does it refer to interactive communications (e.g. conferencing)? Also on Slide 15, the following were indicated as suited for Http3Transport: - General Web applications - Web Chat - Push Notifications Are these the only use cases enabled by Http3Transport, or are there others? --000000000000c2f1f805ab136ccb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Victor said:=C2=A0

""Back when t= he original idea of WebTransport was forming, the hope was to implement and= ship all four of those, since they all fit different use cases better.=C2= =A0 =C2=A0After talking more to the people at IETF, it sounds like four tra= nsports is a bit too much, and we should settle on two (one over QUIC, and = one over TCP)."

[BA]=C2=A0 This is a good que= stion to ask, given some of the sentiments toward simplicity that were expr= essed at IETF 107 as well as IETF 106.=C2=A0=C2=A0

However, since the four proposals "all fit different use cases better= ", it would seem hard to answer the question without reference to the = use cases.

The WEBTRANS WG Charter envisaged u= se cases as being developed along with the requirements:
"To assist in the coordination with owners of = the WebTransport API, the=C2=A0group will initially deve= lop an overview document containing use cases=C2=A0and r= equirements in order to clarify the goals of the effort."=C2=A0=

Since the current Overview Document doesn'= t include use cases,=C2=A0 at this point, the best list we have is the one<= /font>=C2=A0presented at IETF 106 (slide 12):=C2=A0
  • Machine learning

  • Web games

    • =

  • Live streaming

  • Cloud ga= ming

  • Remote desktop

  • Web chat


<= div>The division of these use cases between QuicTransport and Http3/Http2 = transport is not stated on Slide 12, but on slide 15, the following use cas= es were indicated as suitable for QuicTransport:
<= ul>
  • Video games on the Web
  • Real-time media
    • Can we assume t= hat "Video games" corresponds to the "Cloud Gaming" use= case, but perhaps not the "Web games" use case? Does "realt= ime media" correspond to the "machine learning" or "liv= e streaming" use cases, or does it refer to interactive communications= (e.g. conferencing)?

    Also on Slide 15, the following were indicated as suited for Http3T= ransport:
    • General Web applications
    • Web Chat
      =
    • Push Notifications
    = Are these the only use cases enabled by Http3Transport, or are there other= s?
    --000000000000c2f1f805ab136ccb-- From nobody Wed Jul 22 22:57:52 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA0F3A085D for ; Wed, 22 Jul 2020 22:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=FiO8mB92; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S9nBOpUz 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 Ho97Q9sQKZJJ for ; Wed, 22 Jul 2020 22:57:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8613A085A for ; Wed, 22 Jul 2020 22:57:48 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DBF745C00C2 for ; Thu, 23 Jul 2020 01:57:47 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 23 Jul 2020 01:57:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=z+Yyn iu58nm3QFS2OOW3EQMpLUyRVRmAXVRNtmbSRkI=; b=FiO8mB92ZIlQ8dCxX1L/D 4Z1RgNw3p+r2bphubxRo0e+y+gu3TT5meFW8TN1ctx/bBZnWKZwXJkD8KhmUhNVy d8HF8jhVxGem9qyWu3qb1TdhOEjQeDpi/sI3w6EBdygOEPetNy/XzfyfhzSUQedm J3U81rlspaoakBsnF9a3PR/kOc5ObDFCxsKNSakJYylmo4usryEjjcHAvamT76Ag SoWUZ90l1OorXVqUPB8ly5Rv0uToMxRDOxoM141iaN0OEO7ev/hd/FJHgCTAfuVu Vv/aqbCeQJPPUhhDTCcuRSA6CgfFlR3yWMTvqnvFZdVRXErvVojPO+P5x5SUTL8e A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=z+Yyniu58nm3QFS2OOW3EQMpLUyRVRmAXVRNtmbSR kI=; b=S9nBOpUzqfC5WkPN/g9vbBy/74/ELjU8EerH4iS/PYt2MbcITgic9Kf8E Ve6DUUZuoPN20j/rPwuk0+s02IfJ45ewFojZC+maaMCvVbcfslcRshsQ5HuLPFoV jEFutqyNp8Ro7EAUq8W6Y5NDqX5nYwbgLPfWYaJCbWWOP4TpomAajOHfa0fB+V7v sZZv1mQqCDUj3+g8Jorx62d6AiR4niAimfwwLXCri0B6SrHIzx3/jYcJjji/iYpo K6F3RFQ5bzMDdvx+eONTM3yfLEeb3QHdkUKwQXQuawriaB5lWmAlZkz8ru7KiYTp utBbfYT3Psa+FxrZolNSnI4r5z5Tg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedtgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepudduvdehjeetfeeuge eiudektefffeeftdffveffteefgeffhefgtdetuedvffelnecuffhomhgrihhnpehivght fhdrohhrghdphhhtthhpvddrthhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 894ACE00A8; Thu, 23 Jul 2020 01:57:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <3c3dd70a-a2f4-42f2-95c3-913c3afe3fb7@www.fastmail.com> In-Reply-To: References: Date: Thu, 23 Jul 2020 15:57:26 +1000 From: "Martin Thomson" To: webtransport@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 05:57:50 -0000 Thanks for the summary Victor, that really helps frame things. There are other differences, I think, so it would be good to make sure t= hat we've captured all the relevant ones before making a call. And unde= rstanding all the implications of each is important. The one that comes to mind is the way that fallbacks work. In HTTP, you= can imagine leaning heavily on the HTTP mechanisms for QUIC upgrade (or= TCP fallback), like Alt-Svc and so forth. The questions raised regardi= ng non-uniform support for features are relevant here, so this isn't com= pletely free. In another scheme, you can code the fallback directly, ev= en to the point of having it in the API: connect(quicTransport=3Dquic-tr= ansport://..., webSocketTransport=3Dwss://...). In other words, a clean= slate means that you have to build the features you want, but you don't= necessarily have to deal with the baggage you might not. I haven't formed an opinion on this yet. I have a few concerns/wrinkles= to add below though. On Thu, Jul 23, 2020, at 07:23, Victor Vasiliev wrote: > I was previously concerned that having to=20 > implement HPACK/QPACK would be a burden to the Web developers since=20= > those are more complex than what you=E2=80=99d typically find in a Web= Socket=20 > implementation, but now that we have a draft to turn compression off=20= > , I=E2=80=99m l= ess=20 > worried about this. I think that suggests some additional complexities. You have to impleme= nt all of that stack, and trust that browsers do so as well. As we have= learned, sourcing a new capability like this isn't necessarily free. A= nd this seems at least on-par with ALPN in terms of operational costs fo= r server deployments. Maybe it is less of a concern as webtransport end= points are the only ones that need upgrading, but I don't see this as an= easy solution. > While on the surface the question here is =E2=80=9Cwhich drafts should= we=20 > adopt?=E2=80=9D, I would like to break this question down into two lay= ers: I think that there is question zero: do we need to pick one set, or do w= e need to build all four protocols? We have not seen sufficient justification for building four protocols ra= ther than two, so I'm firmly in the "do less work camp" on this. > 1. Do we want to use the wire format in which we try to build=20 > minimally on top of QUIC (QuicTransport), or do we base it on HTTP? > 2. To what extent WebTransport connections act like HTTP connections?= =20 > Do they have https URLs or a dedicated schema? Which HTTP headers do=20= > and don=E2=80=99t work? I think that the answer to the second depends on the first. As much as = possible I would prefer NOT to mint new URI schemes, but that is much ha= rder if you define a completely new protocol. I think that an important= question to resolve before this (1.5?) is how these connections integra= te into the origin model. From nobody Thu Jul 23 06:12:16 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725073A0AA8 for ; Thu, 23 Jul 2020 06:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Pw8sOLGfD3bZ for ; Thu, 23 Jul 2020 06:12:13 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 318503A0AA6 for ; Thu, 23 Jul 2020 06:12:13 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id q4so6304748lji.2 for ; Thu, 23 Jul 2020 06:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3hNhSRj0p5HDaIqaXDG/QGsUYFpa6wsu4D16qthHikM=; b=l3G+t4QDc+xnrKObOwWDOeODmFfnJw0GxBqLuPK49cKZ7AgYp1iuTXWuyTARxSfD41 UxL1oXdT0LhcBhw7urv74A+NyI2LbVYaZ6HI/9siTw5qMRXEgXWF1BZOmRhNVeOGHiwp oNMk0R3nZb1EvEtEAd05tT5kaw4U7fQZx6Z0GfcmBa22UFmmp6mJhuiz7gpf6vlbvrcR PNxt912h7OGqSyoTzYOOUE8T1zm198pbnbNb25DNglXXn0711hWiP1KsTDDIRGlgU8ba Kns+zoBQ5abQ41hTxix21RRNeBycs6ClGo5CypjLloqsZXE1BUDB74A/E8NQDtkUhATd 8f0A== 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; bh=3hNhSRj0p5HDaIqaXDG/QGsUYFpa6wsu4D16qthHikM=; b=VTUOoW21W7VntL21PP1dGfaqQCar2uDHjZwqTRsz2UG2bI42bS3FTHEF24WqLny0qv R1YdWZxHKRdPHb1I+g7730XjRNdJlOlC9M3rgkGSSMlse2XGbwBWofyTtUc7U9CU6vv2 37D7QVXyP9d6yqLKEIQoCpqXD6Vz79ifR/wRsc6P4IjXxo1Zcz8oEALCzGvQcbczgUVa t2Vgw8rOaMkMUJoTRm1hIWt0OqSlcR0cQi5oH1rlG+vinK8kXJuljZ7v2Xlh9HNY943q Wb+KpAMhuHqAsHcWuMaQae1C6b5liLyDZFYajl+huSwjwOW9AFtA877QottjPypFzuCE b5ag== X-Gm-Message-State: AOAM530pV+lo8CgXxu74c/eeBy95kuOaA1LJZ0mfrD44klfS6OXdZL2t Po3x1UW14xKCQbzyJubvSJgTwOF4dGtB41VyVTO9TqVc X-Google-Smtp-Source: ABdhPJzvaImDUnCiq8nJsZZwGi4Z1NGEQCk+j1BvTbYgAqSV51PvVNTbQXfWEAXVygMKEklqJZjuvFydVPjfsc0xIy4= X-Received: by 2002:a2e:8296:: with SMTP id y22mr2065549ljg.238.1595509930987; Thu, 23 Jul 2020 06:12:10 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Thu, 23 Jul 2020 06:12:00 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000ac152605ab1b9a87" Archived-At: Subject: [Webtransport] Volunteers for Jabber Scribe and Note taking X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 13:12:14 -0000 --000000000000ac152605ab1b9a87 Content-Type: text/plain; charset="UTF-8" At the IETF 108 WEBTRANS meeting on July 27, we are going to need volunteers for Jabber Scribe and Note Taking. Any volunteers? --000000000000ac152605ab1b9a87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    At the IETF 108 WEBTRANS meeting on July 27, we are going = to need volunteers for Jabber Scribe and Note Taking.=C2=A0

    <= div>Any volunteers?
    --000000000000ac152605ab1b9a87-- From nobody Thu Jul 23 06:53:16 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B320E3A03ED for ; Thu, 23 Jul 2020 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 8pNHLE5Nljjr for ; Thu, 23 Jul 2020 06:53:14 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 15D163A02C1 for ; Thu, 23 Jul 2020 06:53:14 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id i80so3290986lfi.13 for ; Thu, 23 Jul 2020 06:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6DOahj6YWruUvSIXEcO3KD1wIBdsikV5qFd0wR7TSA8=; b=j5c/qWVD60l/03olXxav0HIrGdV/jMlqIzsPuVdr4lUr+V3A7WQLuRvVFVzHfLvCbA tTEWvibixkqvcrDXpuo7dDNy65JZ/OlyTt+OuLYWUa6XV0+q2iVl78q2S01U+LOBUyqB pcbGxgEHNWeyN/W5NQwm0vtv+T1XEeK0R/eq4DFALMl65F4GcIL74qdQLTMp7o+NSh14 8yTcRJzX79sz7ITd0FDY+8Rn+xl4ZsoxuMWYT1qlrh94Q8Da0dY1/iOwABhjU5yHHkcj dRtCc+ID6pVll3zeYYi2kmUHdf/LES8xtucdNs4nCw3Kq/khgj6owEvzBBMnQL3xo39z LIIg== 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; bh=6DOahj6YWruUvSIXEcO3KD1wIBdsikV5qFd0wR7TSA8=; b=qyK1I/3KYo1xFfA07+LafFq+Ts/ZkbKTP5UhLZ6r1ut1L82/CdFHM/9zY/U0dtdOnF Xe6tBacLdKSXuJcCmSXKSXD0suXKAWx1I7JSgpx62r4kRgK+p0pajF/C7p323zGKZzWU hnYbuAvdzqiyqj25cM1bGRXAIcQG547KyIEiRIfPK5oWkHoNQmOD5J4c5EFcNHLniR2o fbMqsY2qjS6hzcxm6iApA6N4N35TTDX4Bh35RmW8V6OYa0Nq6beAPlNouWy0div2AeVX YkWfrI/4BcyqRSALqxAVAWe3gTmJqZtEU4LlCbNDFFFEIELOYPJsu3j4gK6WAJ4XHPmM 6jMg== X-Gm-Message-State: AOAM531dKDLwgYFx2ilY+uPCIKlr1RXFhBT8bRZhPh96v+/dfNKEgvWZ XbmbiPSzdTvrDowa/cBGZy32X0/YoKvTy602o0IW4SepMWM= X-Google-Smtp-Source: ABdhPJynJbRbe8RBroeISBiZHlsxhi8chHyYGxkunTs2kGlmk59SUgjLqjDrbYNItzeUGmp5qg3GtYHliOptgMiP63s= X-Received: by 2002:ac2:4144:: with SMTP id c4mr2327222lfi.118.1595512392003; Thu, 23 Jul 2020 06:53:12 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Thu, 23 Jul 2020 06:53:01 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="0000000000005c3da105ab1c2d9f" Archived-At: Subject: [Webtransport] IETF 108 MeetEcho Documentation X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 13:53:16 -0000 --0000000000005c3da105ab1c2d9f Content-Type: text/plain; charset="UTF-8" For IETF 108, we will be using MeetEcho to host the meeting. Documentation on using MeetEcho at IETF 108 is available here: https://www.ietf.org/media/documents/Documentation-Meetecho-IETF.pdf Here is the link to the MeetEcho room: http://www.meetecho.com/ietf108/webtrans/ A participant guide to MeetEcho is here: https://www.ietf.org/how/meetings/108/session-participant-guide/ One important thing to note is that IETF 108 registration and a datatracker account will be required to attend the meeting. --0000000000005c3da105ab1c2d9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    For IETF 108, we will be using MeetEcho to host the meetin= g.=C2=A0 Documentation on using MeetEcho at IETF 108 is available here:=C2= =A0

    =
    Here is the link to the MeetEcho room:=C2=A0http://www.me= etecho.com/ietf108/webtrans/

    A participant gui= de to MeetEcho is here:=C2=A0

    One import= ant thing to note is that IETF 108 registration and a datatracker account w= ill be required to attend the meeting.=C2=A0
    =C2=A0
    --0000000000005c3da105ab1c2d9f-- From nobody Thu Jul 23 11:33:52 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523623A0D32 for ; Thu, 23 Jul 2020 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 PyuF5Uu_ZjN8 for ; Thu, 23 Jul 2020 11:33:44 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 85B163A0D47 for ; Thu, 23 Jul 2020 11:33:38 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id u6so2145400uau.8 for ; Thu, 23 Jul 2020 11:33:38 -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=dME7PemwXqrbP4ozpgqFWjol8zlkJ57ulF6wkzh4JbE=; b=JrD+p9itTJjBbSwu/HkkQgbtqJDqJ4hyMoyJzSp+gomsRlKLSuYfO//PuDJD9rca2V JY5vltngnqqEt90LPyVm6jh8R/0qyePoZnJ7P8K+ONCdx1NkAdpv3od3AzfdYTJbtZe2 UqpDPURR5YLwcLREA9bKix/T53WzkfszBsQkGrcfVZ5vLBym8uIrIQDOVjTAhVG6d9sf u964fW9Wf+uaU8JjLjokGHe7rPkzbbm7YFHyGv2jecussbHQnoM3L5k9ScAKh4yHDsZz uZjI+TCtAZwpdRi6jTNWUAaMzeAIXOom9/oOlH0HY7Vmaq6fT6w09lahoCF8ijCGjt2Z F1lQ== 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=dME7PemwXqrbP4ozpgqFWjol8zlkJ57ulF6wkzh4JbE=; b=nKb8TcuEt1q3BFk3WwGXwz6xPqE+XII75bu7u9z6JCu36uxM+ssevzhKjjZ991Rqgt JvP384njNe5UyJQtF4k7FFhizSRgRONymeKsKQkVWlYD+9ZFEjgW4UiBH9Dw1NLAQ/A8 Zyq4hzPNiCMaQjJP44fEnijbquig95Ud+BZZKUTWExHvJeBavIqo1IKftcM4SfGEIUn0 up24nvW1GHN3wOjHZwBksfYpjBBS0smERT5rmifOemMwhjn9/2DMdbK66lY7ac2w/nXv +hStwrqHZ9jhSS47GswLJYFxnxig3bGspo1kuAArFEul85ACXEi/M7NNyi0gm3/BTUBB YRgA== X-Gm-Message-State: AOAM530O8oYADRh58HN/kHyJSbq3H3VIFdul7ZXpGMof/QlqwTG0bDVF rWXIk0h2SqXMtE2LsInw1WrInzhqSo9R4MCf9hc= X-Google-Smtp-Source: ABdhPJwfSDU4g/hePuCJFYhxrHksustoZA23z/fwFSy3hi8HvzWyq4x+eEmma5IC8yaH260LfniLc6F0agAJPVzR4PU= X-Received: by 2002:ab0:29cb:: with SMTP id i11mr5375826uaq.12.1595529217334; Thu, 23 Jul 2020 11:33:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: virat tara Date: Fri, 24 Jul 2020 00:03:20 +0530 Message-ID: To: Victor Vasiliev Cc: WebTransport Content-Type: multipart/alternative; boundary="0000000000003a610e05ab2018a8" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 18:33:51 -0000 --0000000000003a610e05ab2018a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, For an app that would use both regular HTTP calls and WebTransport, from the server's perspective, won't using HttpTransport instead of a dedicated connection like in QuicTransport help it to reduce the number of active connections/sockets per client? Thus allowing it to serve more distinct clients per server. Particularly for apps that make occasional HTTP calls and heavily rely on a full-duplex protocol for the rest of their working. On Thu, Jul 23, 2020 at 2:53 AM Victor Vasiliev wrote: > Hello everyone, > > We recently adopted the overview draft > that > describes the general requirements for and the model of WebTransport. > However, we haven't yet adopted any specific wire protocol proposals. > There are currently three of those presented to the working group: > > - QuicTransport > > - Http2Transport > > - Http3Transport > > - [hypothetical WebTransport over WebSocket] > > Back when the original idea of WebTransport was forming, the hope was to > implement and ship all four of those, since they all fit different use > cases better. After talking more to the people at IETF, it sounds like > four transports is a bit too much, and we should settle on two (one over > QUIC, and one over TCP). The natural picks would be either Http3Transpor= t > with Http2Transport as fallback (HttpTransport for short), or QuicTranspo= rt > with=E2=80=A6 *something* as a fallback. Let=E2=80=99s look at the diffe= rences between > those two options. > > *Differences* > > The most substantial wire format difference between those two proposals i= s > the handshake. QuicTransport originally did not have any handshake; we h= ad > to add a bespoke handshake later in order to implement the Origin header, > and we also added a Path header later on. We currently don=E2=80=99t hav= e any form > of response headers, so if the server is unhappy with the origin or path > received, it has to close the connection with CONNECTION_CLOSE.. In > HttpTransport, we have regular HTTP header fields for both request and > response, meaning that the server can do things like return a 4xx/5xx for > an error. > > During the connection itself, the difference is minimal: QuicTransport > uses streams and datagrams as-is, while Http3Transport prefixes everythin= g > with an ID, since it is multiplexed with other HTTP traffic. There might > be a question of whether prefixing can impose undesirable framing overhea= d; > I think if that ever becomes a serious problem, we can come up with some > extension to work this around. > > If we decide that QuicTransport is a way to go, we=E2=80=99d have to add = more > features into its handshake, since I suspect most people won=E2=80=99t be= happy > with what=E2=80=99s in there right now (HTTP headers like Location or For= warded > would be a good example of what people would end up needing in practice, > together with an ability to tag along arbitrary key-value metadata for > debugging purposes). If we decide that HttpTransport is a way to go, we > would have to ensure that the result is easy for Web developers to use, a= nd > that we understand the differences between it and regular HTTP. > > From the server complexity standpoint, I am not particularly worried abou= t > either. We=E2=80=99ve implemented QuicTransport in Chrome, and I wrote t= wo servers > for it, in C++ and in Python; the Python one took about 100 lines of code= . > Http2Transport has been implemented, in somewhat different forms, by both > Apple and Facebook, so we have practical experience with it too.. I was > previously concerned that having to implement HPACK/QPACK would be a burd= en > to the Web developers since those are more complex than what you=E2=80=99= d > typically find in a WebSocket implementation, but now that we have a > draft to turn compression off > , I=E2=80=99m less= worried > about this. > > There is a question of how much of the HTTP ecosystem we would be actuall= y > getting by adopting HTTP. It is true that basing WebTransport on HTTP do= es > not mean HTTP middleware would automatically implement it. That said, we > do get a lot of useful features from HTTP, notably message routing and a > well-understood metadata format. Everyone knows what a code 200 or 404 i= s, > and a lot of people have built their internal debugging/tracing tools bas= ed > on adding HTTP headers to things, and being able to easily port those to > WebTransport would be an asset. I=E2=80=99ve seen some arguments that co= ntent > negotiation and caching might be applicable to certain classes of > WebTransport resources too (e.g. a live stream can be cached in the sense > that requesting a live stream is joining it), though those kinds of cases > would have to be content-specific and they do not generalize as nicely as > caching for regular HTTP resources. An interesting point to note is that > WebTransport is always included programmatically (as opposed to being > navigated to or sourced via URL from HTML), thus alleviating the need for= a > lot of otherwise useful HTTP headers. > > *Questions* > > While on the surface the question here is =E2=80=9Cwhich drafts should we= adopt?=E2=80=9D, > I would like to break this question down into two layers: > > 1. Do we want to use the wire format in which we try to build > minimally on top of QUIC (QuicTransport), or do we base it on HTTP? > 2. To what extent WebTransport connections act like HTTP connections? > Do they have https URLs or a dedicated schema? Which HTTP headers do = and > don=E2=80=99t work? > > > Regarding the first issue, I am increasingly leaning towards keeping only > the HTTP-based option. QuicTransport=E2=80=99s most appealing feature is = its > simplicity; however, ever since we=E2=80=99ve had to add a header to comm= unicate > the Web origin, there has been increasingly more and more reasons to add > new features to it, so even if we go that way, we=E2=80=99re probably goi= ng to end > up with something that=E2=80=99s a lot like HTTP. Also, we know exactly = how to do > TCP fallback in this case, so this removes a lot of design problems from > consideration. Fixing complexity and other problems with HTTP is probabl= y > more viable. > > Regarding the second issue, I am not sure how much of it is in scope for > this working group. While we do need to define a URL schema, and the > choice of schema will give us a lot of answer (by making WebTransport sam= e > or different origin as HTTP), a lot of those questions have been > traditionally answered somewhere in Fetch spec, or simply not addressed i= n > the standards at all. I am not quite sure what to do with those. > > What do people think? > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --0000000000003a610e05ab2018a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,

    For an app that would use both regu= lar HTTP calls and WebTransport, from the server's perspective, won'= ;t using HttpTransport instead of a dedicated connection like in=C2=A0QuicT= ransport=C2=A0help it to reduce the number of active connections/sockets pe= r client? Thus allowing it to serve=C2=A0more distinct=C2=A0clients per ser= ver. Particularly=C2=A0for apps that make occasional=C2=A0HTTP calls and he= avily rely on a full-duplex protocol for the rest of their working.

    On= Thu, Jul 23, 2020 at 2:53 AM Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:<= br>
    Hello everyone,

    We recent= ly adopted the overview draft that describes the general= requirements for and the model of WebTransport.=C2=A0 However, we haven= 9;t yet adopted any specific wire protocol proposals.=C2=A0 There are curre= ntly three of those presented to the working group:
    • QuicTransport
    • Http2Transport
    • <= a href=3D"https://tools.ietf.org/html/draft-vvv-webtransport-http3-02" targ= et=3D"_blank">Http3Transport
    • [hypothetical WebTransport over We= bSocket]
    Back when the original idea of WebTransport was forming, = the hope was to implement and ship all four of those, since they all fit di= fferent use cases better.=C2=A0 After talking more to the people at IETF, i= t sounds like four transports is a bit too much, and we should settle on tw= o (one over QUIC, and one over TCP).=C2=A0 The natural picks would be eithe= r Http3Transport with Http2Transport as fallback (HttpTransport for short),= or QuicTransport with=E2=80=A6 something as a fallback.=C2=A0 Let= =E2=80=99s look at the differences between those two options.

    Dif= ferences

    The most substantial wire format difference between tho= se two proposals is the handshake.=C2=A0 QuicTransport originally did not h= ave any handshake; we had to add a bespoke handshake later in order to impl= ement the Origin header, and we also added a Path header later on.=C2=A0 We= currently don=E2=80=99t have any form of response headers, so if the serve= r is unhappy with the origin or path received, it has to close the connecti= on with CONNECTION_CLOSE..=C2=A0 In HttpTransport, we have regular HTTP hea= der fields for both request and response, meaning that the server can do th= ings like return a 4xx/5xx for an error.

    During the connection itsel= f, the difference is minimal: QuicTransport uses streams and datagrams as-i= s, while Http3Transport prefixes everything with an ID, since it is multipl= exed with other HTTP traffic.=C2=A0 There might be a question of whether pr= efixing can impose undesirable framing overhead; I think if that ever becom= es a serious problem, we can come up with some extension to work this aroun= d.

    If we decide that QuicTransport is a way to go, we=E2=80=99d have= to add more features into its handshake, since I suspect most people won= =E2=80=99t be happy with what=E2=80=99s in there right now (HTTP headers li= ke Location or Forwarded would be a good example of what people would end u= p needing in practice, together with an ability to tag along arbitrary key-= value metadata for debugging purposes).=C2=A0 If we decide that HttpTranspo= rt is a way to go, we would have to ensure that the result is easy for Web = developers to use, and that we understand the differences between it and re= gular HTTP.

    From the server complexity standpoint, I am not particul= arly worried about either.=C2=A0 We=E2=80=99ve implemented QuicTransport in= Chrome, and I wrote two servers for it, in C++ and in Python; the Python o= ne took about 100 lines of code.=C2=A0 Http2Transport has been implemented,= in somewhat different forms, by both Apple and Facebook, so we have practi= cal experience with it too..=C2=A0 I was previously concerned that having t= o implement HPACK/QPACK would be a burden to the Web developers since those= are more complex than what you=E2=80=99d typically find in a WebSocket imp= lementation, but now that we have a draft to turn compression off<= /a>, I=E2=80=99m less worried about this.

    There is a question of how= much of the HTTP ecosystem we would be actually getting by adopting HTTP.= =C2=A0 It is true that basing WebTransport on HTTP does not mean HTTP middl= eware would automatically implement it.=C2=A0 That said, we do get a lot of= useful features from HTTP, notably message routing and a well-understood m= etadata format.=C2=A0 Everyone knows what a code 200 or 404 is, and a lot o= f people have built their internal debugging/tracing tools based on adding = HTTP headers to things, and being able to easily port those to WebTransport= would be an asset.=C2=A0 I=E2=80=99ve seen some arguments that content neg= otiation and caching might be applicable to certain classes of WebTransport= resources too (e.g. a live stream can be cached in the sense that requesti= ng a live stream is joining it), though those kinds of cases would have to = be content-specific and they do not generalize as nicely as caching for reg= ular HTTP resources.=C2=A0 An interesting point to note is that WebTranspor= t is always included programmatically (as opposed to being navigated to or = sourced via URL from HTML), thus alleviating the need for a lot of otherwis= e useful HTTP headers.

    Questions

    While on the surface = the question here is =E2=80=9Cwhich drafts should we adopt?=E2=80=9D, I wou= ld like to break this question down into two layers:
    1. Do we want = to use the wire format in which we try to build minimally on top of QUIC (Q= uicTransport), or do we base it on HTTP?
    2. To what extent WebTranspor= t connections act like HTTP connections?=C2=A0 Do they have https URLs or a= dedicated schema?=C2=A0 Which HTTP headers do and don=E2=80=99t work?
      3. =

    Regarding the first issue, I am increasingly leaning towards keepi= ng only the HTTP-based option. QuicTransport=E2=80=99s most appealing featu= re is its simplicity; however, ever since we=E2=80=99ve had to add a header= to communicate the Web origin, there has been increasingly more and more r= easons to add new features to it, so even if we go that way, we=E2=80=99re = probably going to end up with something that=E2=80=99s a lot like HTTP.=C2= =A0 Also, we know exactly how to do TCP fallback in this case, so this remo= ves a lot of design problems from consideration.=C2=A0 Fixing complexity an= d other problems with HTTP is probably more viable.

    Regarding the se= cond issue, I am not sure how much of it is in scope for this working group= .=C2=A0 While we do need to define a URL schema, and the choice of schema w= ill give us a lot of answer (by making WebTransport same or different origi= n as HTTP), a lot of those questions have been traditionally answered somew= here in Fetch spec, or simply not addressed in the standards at all.=C2=A0 = I am not quite sure what to do with those.

    What do people think?
    =
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --0000000000003a610e05ab2018a8-- From nobody Thu Jul 23 13:04:19 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1883E3A0D33 for ; Thu, 23 Jul 2020 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Ts6tr5bBhY9Y for ; Thu, 23 Jul 2020 13:04:17 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 448003A0D27 for ; Thu, 23 Jul 2020 13:04:17 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id p3so3728436pgh.3 for ; Thu, 23 Jul 2020 13:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:date:subject:message-id :cc:to; bh=7H/VvYGZHOB1dC8PkyvqvWuYDfuJr2KdQEa7eP/uH7E=; b=UPWWlMwWH4rJUTBSNDPfsYnyBTjxqiCKR7Ot2iA9xvzYl+V8XEtmKzd/PfuDSbt/PF XqImzcX5XjfYm/suaS7W3AYR4WLg2XRyowjByNa7OkQ5vgeKQE4FTVs3dnF/A/os3DwR zLq5Y3MMFVIvGFKZsaPmoOAqaBQiBs06HlyPdY+SBv1vp1yiBuMg7WByjpbhSj1bX02g GWxrFtg+2svJXrVoC/cLwWeSB0hDX6kwJ4H/B1reoxX4E9iYiR0KFZKIUci2vlEJQbgK HeH762s+sX24Z+Ds9zZGzGojfDIJ62iCQjryxbGIZ8sKCj6f6ndqOBDkgLPz8HW4B3jC cCGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:cc:to; bh=7H/VvYGZHOB1dC8PkyvqvWuYDfuJr2KdQEa7eP/uH7E=; b=SEn+ZCpds+DtvdM11tiO+VmH4ewVP9k9Bi8j8w5aFXptnO4Ojmve7Nhpd6sVSUY+tS Fqo+7QaxjudnemBTv2T1Qee7SSkjJ3PNEjUZXD6CHnxt5GtAXZcCQDKBOB6kfx3L1c8h nRdHaYHm5vvUBfA/IdoHUSk0eowuEJuYUVYW27dZG4wNt6Cln/nzD/VlIsZFJKRe4Frv ezriCMHhKbbDWg51m4xDn7e14LGbEqKqHEbR0SiK66SNlcZEo7uABwPyNTuynvFYyttn YXaEeFp8en26ayy/praXE2HTJF5tWzjkYpRiFTuQx7dCZuWm1FIIb52RU1kVp43QZ8E9 tlBg== X-Gm-Message-State: AOAM533w9QJPjESC3my/+hZabddbz4vF6MjC72LM+PnVAZO/JhTP3Gx4 4ehIU7BwYAv3pno/HhWGS9mRyWB3oRM= X-Google-Smtp-Source: ABdhPJwzVLVftj4emcUgRIQp0bYK3J/CDgq10JJ8KpTQVSGGVpFQOrMYC8oddfD3W90D/2/VWIkE5Q== X-Received: by 2002:a63:4b04:: with SMTP id y4mr5606584pga.158.1595534655380; Thu, 23 Jul 2020 13:04:15 -0700 (PDT) Received: from [192.168.1.103] (c-71-227-236-207.hsd1.wa.comcast.net. [71.227.236.207]) by smtp.gmail.com with ESMTPSA id y65sm3822580pfb.75.2020.07.23.13.04.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2020 13:04:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Thu, 23 Jul 2020 13:04:13 -0700 Message-Id: <820780C1-6922-48A4-81F5-2D69706F5B3D@gmail.com> Cc: Victor Vasiliev , WebTransport To: virat tara X-Mailer: iPhone Mail (17G68) Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:04:18 -0000 Virat =E2=80=94 The ability to share a QUIC connection between HTTP3 (e.g. fetch) and WebTra= nsport (via WebTransport API) has come up from time to time. Do you have a u= se case where this would be valuable? > On Jul 23, 2020, at 11:34 AM, virat tara wrote: >=20 From nobody Thu Jul 23 13:07:29 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8020F3A0D38 for ; Thu, 23 Jul 2020 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVfZ1BGxA_yh for ; Thu, 23 Jul 2020 13:07:26 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 D8FB03A0D34 for ; Thu, 23 Jul 2020 13:07:25 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id a15so6302947wrh.10 for ; Thu, 23 Jul 2020 13:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xj3kAgXEffxIVxT46JwbbP0y8HUFE18aIcxTJXF5au4=; b=vtEe6x+Quc4UKgQuZM01erf7XdCwFSBklElQbxb+p3Ri5+LmqFrOj/Ctxa2PGSxhs1 YkjhLeGE5/xygWYHsryRGvujHAkJSy8NGUzaOtK1rW5aOyAKbV7xm0cVxTpBhFDo1emT yU1tv9HjrttvWwCJkbEJzElf837ui755yB0Wa6rRKs9UP4H2PtlyGd9QT2XjP3/zKKSM zL67HgfpYtk8fnraMgVvWGrGIidgXNne7sRT0e8bS6u5hDNHsnr5ywM6h96luhgauydO jbBl1+UlCUYb6nuJknCH9XXJHDGr5t8KTADx9806JyTtB+T1mm9scnHPCCyeqOD3I0rq YNog== 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=Xj3kAgXEffxIVxT46JwbbP0y8HUFE18aIcxTJXF5au4=; b=S21/aFphJ/rwBMMGzc8xNLeRim+TniXilMnxsIjn33AmFqsAuN/mzE3qDhyH7Es0tc mFOq+hdaI1mel8R5MMFfQ6zlC3esUaw/iPikGbL83wde5Z71Z5RUnAdYh/RvbPq4IONh 3za2Zw78m0fJzUVw0TJmlK2moZxmw2ZX1v6PmUpe00WVccP96yaGUU8rj1g+izQvUZjA kcgdrWGN0nEuIvhrkyH23TpzxMQ+Sb4OEqCkemkeBeUZiLKM8iFI2lYrwhzVk6uHyaaM U6VSrPCD0nE9sW1P8scoGiR9Hy7Eoj95N4eIyLdQbk9H+1179TpboAeH4NIiSz0mbwqY YpZQ== X-Gm-Message-State: AOAM533Sxf7BAGBxkP8iDUHACFu9tm582nuBYL1EhmMtHAMJPt3DL5cP rUP5D9dY3P/Lkyb6r2/2beSO0VpO1gGEkxdg20M6UQ== X-Google-Smtp-Source: ABdhPJyFeZ7gWgyIuROSGys7aAN+ifsWe8LEfHV9uEqV2dN7/GosKtjvitGmBYfZwYHXC1RxtxI9PDPGQnn+5cgvkvc= X-Received: by 2002:a5d:43c4:: with SMTP id v4mr3472714wrr.426.1595534843047; Thu, 23 Jul 2020 13:07:23 -0700 (PDT) MIME-Version: 1.0 References: <820780C1-6922-48A4-81F5-2D69706F5B3D@gmail.com> In-Reply-To: <820780C1-6922-48A4-81F5-2D69706F5B3D@gmail.com> From: Ben Schwartz Date: Thu, 23 Jul 2020 16:07:11 -0400 Message-ID: To: Bernard Aboba Cc: virat tara , Victor Vasiliev , WebTransport Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009fb1ef05ab21673b" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 20:07:28 -0000 --0000000000009fb1ef05ab21673b Content-Type: multipart/alternative; boundary="0000000000008c610805ab216729" --0000000000008c610805ab216729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I view this as useful for both privacy and performance. Bundling different kinds of connections into a single QUIC session exposes less information about the size and timing of transfers, and allows the congestion controller to jointly optimize all of these flows (instead of having multiple congestion controllers fighting over the same link). On Thu, Jul 23, 2020 at 4:04 PM Bernard Aboba wrote: > Virat =E2=80=94 > > The ability to share a QUIC connection between HTTP3 (e.g. fetch) and > WebTransport (via WebTransport API) has come up from time to time. Do you > have a use case where this would be valuable? > > > On Jul 23, 2020, at 11:34 AM, virat tara wrote: > > > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --0000000000008c610805ab216729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I view this as useful for both privacy and performance.=C2= =A0 Bundling different kinds of connections into a single QUIC session expo= ses less information about the size and timing of transfers, and allows the= congestion controller to jointly optimize all of these flows (instead of h= aving multiple congestion controllers fighting over the same link).
    On Thu, = Jul 23, 2020 at 4:04 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
    Virat =E2=80=94

    The ability to share a QUIC connection between HTTP3 (e.g. fetch) and WebTr= ansport (via WebTransport API) has come up from time to time. Do you have a= use case where this would be valuable?

    > On Jul 23, 2020, at 11:34 AM, virat tara <virattara@gmail.com> wrote:
    >

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --0000000000008c610805ab216729-- --0000000000009fb1ef05ab21673b Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCyruthpBptEJznsvu9nGiE46SZwaCJx7mlUwSV7H/eTTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MjMyMDA3MjRaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAR8+Hqd+PuiR3uxPGWfuzqVayLdfjhgrj14+Z4oW+xAFrLO73x0fLzbeuh02vUuwxsdgxGWVD ocexBLq6nZ5mRKtGOPx2RbtUJgruntFnCo3MO8SGb0eESZrvSgZODBEZol655kmd4XlAAl54r/rq ZGvNFk6R7OgrO796OojZJkvs2fEWzYiw5k77ScFclQoArBmz99qtnpHesOJ9qDmRdDzyBXxu6SY+ NA24P/VrSU/yC8xFUfCcVUWJRsDGAG1+UFCOzHhfYJHGTo1hV9UqslN/oD83xo0e9pd4NTWIz1qk LRK1Gdc4Tfft0X7kje2zJxkKMSacu21skGcmVyi2DQ== --0000000000009fb1ef05ab21673b-- From nobody Thu Jul 23 16:58:12 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0A3A09A3 for ; Thu, 23 Jul 2020 16:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=J/etVLYV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D+1CIeML 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 qna3O2ZfUrqV for ; Thu, 23 Jul 2020 16:58:08 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E193A099E for ; Thu, 23 Jul 2020 16:58:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B18825C009F for ; Thu, 23 Jul 2020 19:58:07 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 23 Jul 2020 19:58:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=ex9nJ7Sy7STSZXgqlz917zWcedoxOsr tHQG2zKZB5SU=; b=J/etVLYVpWUngDRHxJQIDPng+5HqjFWBfNnx46Tha/jyLnP /SWlcdQDaYSLTSCszVKctAKJca8FfYlR7K/UiULu/w0Au+gQcAp/bqZgb4bYeo9F kN81SH1YT5yleeIFZA2U/d2WaEnNL6fSsWF9VjIS4Eb8H5FH+neXV4VvTkcvylXW C8urD+d4vBydtpFXA/tMKK+YCMR6R20a4RLjEpvnjhpdU9ArNsjyGkol62Z6GL/a 3QQfHtbhus4jofGFCT10iEdmFzlMkfyFagCDIdfxr8fRHpVfIk8vR1P9xGXjeXNX oOaFiOJ7QuLtmm0ATsYiwuQO0L6BiT9TB2yLQZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ex9nJ7 Sy7STSZXgqlz917zWcedoxOsrtHQG2zKZB5SU=; b=D+1CIeMLBQL7Qc7fJFyeYn g9c1BMRFy0RchBJpe7Xefyc2wJhU6nR1ghUn72R+iQDMBR/Y6gzUh2+7Sp/0RDFV SfAswCzH/NKhr2gqv0tUP4RZiIhA7KadDWipnylOAxcGXJAKnS5AQS/YTAzhbP0h o2bj99GwTM+LA6dZu2WhMfNBx9/B6iqfhVyCIVMYx7N/FQqxVqagEkyHLCn5sztl GJxdspVtDH3w3Ie2WmMq+5b076bOiM/Qfx/DooGh/J0eiJQy3ty6SU3voizvcKma m7uRoBryDAzBFoh6ux+KrNqp1r3Lx45rWzwiB9Fhik9vSOSby823L8hRpk0501Kg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedvgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 70482E00C9; Thu, 23 Jul 2020 19:58:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> In-Reply-To: References: Date: Fri, 24 Jul 2020 09:57:48 +1000 From: "Martin Thomson" To: webtransport@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2020 23:58:10 -0000 On Fri, Jul 24, 2020, at 04:33, virat tara wrote: > For an app that would use both regular HTTP calls and WebTransport, > from the server's perspective, won't using HttpTransport instead of a > dedicated connection like in QuicTransport help it to reduce the number > of active connections/sockets per client? Thus allowing it to serve > more distinct clients per server. Particularly for apps that make > occasional HTTP calls and heavily rely on a full-duplex protocol for > the rest of their working. That's a good point. My understanding of the HTTP mappings is that you can make several "instances" of the WebTransport thing in the one connection. Even if you only have one WebTransport thing, you can still use the same connection for HTTP and the thing. With a dedicated transport, it seems like you just have one. Of course that one is capable of a lot of concurrency, so you might be comfortable with not having multiple sessions, but I can imagine cases for sharing different logical contexts that can be split at a gateway. From nobody Thu Jul 23 18:42:23 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105C33A07FF for ; Thu, 23 Jul 2020 18:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 kPrXCAODrzfB for ; Thu, 23 Jul 2020 18:42:20 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 CAC6E3A07FB for ; Thu, 23 Jul 2020 18:42:19 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id y18so4328121lfh.11 for ; Thu, 23 Jul 2020 18:42:19 -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=r3U0KVQuw6IJB8YjJPqee5XCVIe9APNaMoIaiprDDOE=; b=lbtujPMd3bXueDDqVBB7ypt9WaOAWu0Ij8GpbsOPRTVAp8W66/XM7NAtH09UbwpdMv 7Jd5VLm9rfB5nJ9hhtgqT4kchCoIbpNPn/FvuHDKBsP/P6I5CTdoCgDz7BMd0EgTXsFs UWhfyraHPpggBPdukS0Oyi4mm0R0gRuFeVRM7pYGDO9g1mpIHyNK6GrSTWSYyxgC7YSW FvTpGRPU7GeORIbn76XDbAWgoOWPMBPyhdCvwG5dJ16HfOxy78/agA3goSlUkIfQP5lC YPj+xl2sfU/Ka2IF3gcvmgPzAnmN3iMeFkXbK+DpDhjEQkxf7r6Xbry9xMmyYTawTF17 hTMg== 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=r3U0KVQuw6IJB8YjJPqee5XCVIe9APNaMoIaiprDDOE=; b=DCf3YWtGQ5nhzOAhUTm6d0PuL2G4vQKvROjpvbYM7XT6qB1QvnKMiduLiE9L0I5Hk/ Cn7XuT+VDmMSxpZjLUIA5UbKnTbHQlMFKvOLfWcdZj4LxwbhCJgMXkHL90zQ0dwm0rsz jpGu/AJ1YNDZno2PwUwZLVZZLM7mDzhNl+92EIUjQom8bz9LQj9z00a/C1NNnIMT/dch lT8Gpsu20Hz6KKNawbtTKgyevNVQ85K7TRddYHFyJXoYfH56D6ZekUWfYxOOm5uDxQGr xuXgGbNZDwpjM+zQhmCq0KAp+Ra005H8f2x39Op75Ss6WH2OuZWk9tIbSgUEsoiD2e8e CgFw== X-Gm-Message-State: AOAM533rUfYEukl6h+AfzqhcQnMg0xNxN9ZU51UW0pS3zN15O+gyZVRP JDXBibWNxP7s1SGc6hDz4X6jWGtiWPaMrZFpcf7BTmXmODI= X-Google-Smtp-Source: ABdhPJyk2Evw71NruRqeRWddZ7++qydbpIr/mMJjWsqgreHc/IFQvTx+eQCXqiZsjIEZRvyQHtaFLOdcAdRAUfoAnXs= X-Received: by 2002:ac2:5683:: with SMTP id 3mr3597331lfr.69.1595554937862; Thu, 23 Jul 2020 18:42:17 -0700 (PDT) MIME-Version: 1.0 References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> In-Reply-To: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> From: Bernard Aboba Date: Thu, 23 Jul 2020 18:42:25 -0700 Message-ID: To: Martin Thomson Cc: WebTransport Content-Type: multipart/alternative; boundary="0000000000004a934405ab261501" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 01:42:22 -0000 --0000000000004a934405ab261501 Content-Type: text/plain; charset="UTF-8" Martin said: "That's a good point. My understanding of the HTTP mappings is that you can make several "instances" of the WebTransport thing in the one connection." [BA] Here is the current Http3Transport constructor: [Exposed =(Window,Worker)]interface Http3Transport { constructor(DOMString url ); }; It only takes a url as an argument (like the WebSocket constructor). So the implication is that invoking the constructor creates a distinct QUIC connection. But using that QUIC connection, it is possible to create multiple bi-directional or uni-directional streams or send datagrams in either direction. So "pooling" or other sharing of an Http3Transport is already supported to a significant extent. Martin said: "Even if you only have one WebTransport thing, you can still use the same connection for HTTP and the thing." [BA] Note that the Http3Transport constructor doesn't have an optional QuicTransport object as an argument, so that there's no way to "share" a QUIC transport between Http3 (as used by say, fetch) and Http3Transport. There is a reason why this isn't supported, even though it was something that seemed quite desirable. HTTP/3 is very specific on how it uses Stream IDs, so it would be quite tricky to have both the WebTransport and another API like fetch sharing a QUIC connection. On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson wrote: > On Fri, Jul 24, 2020, at 04:33, virat tara wrote: > > For an app that would use both regular HTTP calls and WebTransport, > > from the server's perspective, won't using HttpTransport instead of a > > dedicated connection like in QuicTransport help it to reduce the number > > of active connections/sockets per client? Thus allowing it to serve > > more distinct clients per server. Particularly for apps that make > > occasional HTTP calls and heavily rely on a full-duplex protocol for > > the rest of their working. > > That's a good point. My understanding of the HTTP mappings is that you > can make several "instances" of the WebTransport thing in the one > connection. Even if you only have one WebTransport thing, you can still > use the same connection for HTTP and the thing. With a dedicated > transport, it seems like you just have one. > > Of course that one is capable of a lot of concurrency, so you might be > comfortable with not having multiple sessions, but I can imagine cases for > sharing different logical contexts that can be split at a gateway. > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --0000000000004a934405ab261501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Martin said:=C2=A0
    <= br>
    "That's a good point.=C2=A0 My understanding of the = HTTP mappings is that you can make several "instances" of the Web= Transport thing in the one connection."

    [BA] = Here is the current Http3Transport=C2=A0constructor:=C2=A0

    [Exposed=3D(Window,Worker)]
interface Http3Transport {
  constructo=
r(D=
OMString url=
);
};

    It only takes a url as an argument (like = the WebSocket constructor).=C2=A0 So the implication is that invoking the c= onstructor creates a distinct QUIC connection.=C2=A0 But using that QUIC=C2= =A0connection, it is possible to create multiple bi-directional or uni-dire= ctional streams or send datagrams in either direction.=C2=A0 So "pooli= ng" or other sharing of an Http3Transport is already supported to a si= gnificant extent.=C2=A0

    Martin said:=C2=A0
    "Even if you only have one WebTransport thing, you can still use th= e same connection for HTTP and the thing."=C2=A0

    <= div>[BA]=C2=A0 Note that the Http3Transport=C2=A0 constructor doesn't h= ave an optional QuicTransport object as an argument, so that there's no= way to "share" a QUIC=C2=A0transport between Http3 (as used by s= ay, fetch) and Http3Transport.

    There is a reason w= hy this isn't supported, even though it was something that seemed quite= desirable. HTTP/3 is very specific on how it uses Stream IDs, so it would = be quite tricky to have both the WebTransport and another API like fetch sh= aring a QUIC connection.=C2=A0


    =

    On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson <mt@lowentropy.net> wrote:
    On Fri, Jul 24, 2020, at 04= :33, virat tara wrote:
    > For an app that would use both regular HTTP calls and WebTransport, > from the server's perspective, won't using HttpTransport inste= ad of a
    > dedicated connection like in QuicTransport help it to reduce the numbe= r
    > of active connections/sockets per client? Thus allowing it to serve > more distinct clients per server. Particularly for apps that make
    > occasional HTTP calls and heavily rely on a full-duplex protocol for <= br> > the rest of their working.

    That's a good point.=C2=A0 My understanding of the HTTP mappings is tha= t you can make several "instances" of the WebTransport thing in t= he one connection.=C2=A0 Even if you only have one WebTransport thing, you = can still use the same connection for HTTP and the thing.=C2=A0 With a dedi= cated transport, it seems like you just have one.=C2=A0

    Of course that one is capable of a lot of concurrency, so you might be comf= ortable with not having multiple sessions, but I can imagine cases for shar= ing different logical contexts that can be split at a gateway.

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --0000000000004a934405ab261501-- From nobody Thu Jul 23 19:20:21 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9B03A07A9 for ; Thu, 23 Jul 2020 19:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=SjuQdnMP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zn3aNGc9 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 beAamXUTkwBI for ; Thu, 23 Jul 2020 19:20:19 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19A43A07D4 for ; Thu, 23 Jul 2020 19:20:18 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 539705C0091; Thu, 23 Jul 2020 22:20:18 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 23 Jul 2020 22:20:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=+Qd2m1eYM9TxrInyMpZyDq/1EDgE e9mhcLt/spgHsQg=; b=SjuQdnMPJD52sDICsbPH+kBvlHAJ9TMfP7kz+huKFflR LxailDQceclrkeUJh0dUNUFaPRtB2OSzIdXZ5fEcbwsjpYNyPBDJur3Z5goxUWN8 XbXAeUYBzP5U09heND9eCDAOAXjcgALdkohtKD+8Rla9cy3gVijmE+hqbyTui8ap RVmq6bp8LqIrQ4dp7bMMUedkBHu82glxTiXSZxFCExl9r0ZSTjeeE/VuwH8hlsxJ H9oZZXxZMRexKWbbPTdUfQEG0BSV9TTU0Fqt+cczLqzNTwcj0cIo0HMewaOC6OR1 Lznp9+zgy9ChMm+ATow+uKTqND7De2BVOoEZx9CmMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+Qd2m1 eYM9TxrInyMpZyDq/1EDgEe9mhcLt/spgHsQg=; b=Zn3aNGc9qxdC6WiC+Ra355 DzQ1QWm8n6iJicYp9vePoqvOIS9pIJFI+6YkB7hfb/gh8p0SN5b1fQL3XZTtWU2k rCvEd2cg6hnVTmKjU5EvfA+RSRSbE+L71RRGEpVQ9jkw2DAJhJIr7xKPKRFzvNEJ wYtJ/4UUXAk9L/YKzjJjnLftHtTg0vX6A+RJdurUzF8vY1UrVYmJFFgmBzzCgboY vHz8KCVG4iNmkE516laEvc8vIVzA3Lw+3BAUiHm7Zq6FLkuJGQM6yLjHaSBP//Ey Mngi1kF/9n+/uyO0afsicSg5TrNbjIEqySb/CFx6OADe6+SbiFSvuaY59LcL3kJw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedvgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeeflefhgeefkeehffejheeiffefheehieetjedtvddtffelleefjeev gfffueekieenucffohhmrghinhephhhtthhpnhhtrhgrnhhsphhorhhtihifohhulhgurh gvghgrrhguthhhrghtrghsrgguvghsihhgnhgvrhhrohhrrdgsrgenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhoph ihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5F915E00C9; Thu, 23 Jul 2020 22:20:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <3a7c95f9-53cf-4d19-958b-5b4a8eed16f7@www.fastmail.com> In-Reply-To: References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> Date: Fri, 24 Jul 2020 12:19:58 +1000 From: "Martin Thomson" To: "Bernard Aboba" Cc: WebTransport Content-Type: text/plain Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 02:20:20 -0000 On Fri, Jul 24, 2020, at 11:42, Bernard Aboba wrote: > It only takes a url as an argument (like the WebSocket constructor). > So the implication is that invoking the constructor creates a distinct > QUIC connection. How do you go from URL to a single connection? fetch takes a single URL too, but those routinely use existing connections (in all protocol versions). I also don't see the BlahTransport as having any inherent 1-1 mapping with connections. If that is the case for Http[N]Transport, I would regard that as a design error. > [BA] Note that the Http3Transport constructor doesn't have an > optional QuicTransport object as an argument, so that there's no way to > "share" a QUIC transport between Http3 (as used by say, fetch) and > Http3Transport. Again, how did you get there? I realize that there might be reasons why you might want to avoid sharing, like the rules we have for font fetching, but it doesn't naturally follow that you need a new connection for this. > There is a reason why this isn't supported, even though it was > something that seemed quite desirable. HTTP/3 is very specific on how > it uses Stream IDs, so it would be quite tricky to have both the > WebTransport and another API like fetch sharing a QUIC connection. Now we're getting somewhere. I agree that getting access to a bidirectional stream in HTTP/3 is tricky (and a unidirectional stream in HTTP/2 trickier), but surely these are spelling problems, not fundamental barriers to multiplexing. From nobody Thu Jul 23 22:04:23 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4552B3A0BAC for ; Thu, 23 Jul 2020 22:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu8IW9JM3Qn7 for ; Thu, 23 Jul 2020 22:04:20 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 314273A0BAB for ; Thu, 23 Jul 2020 22:04:20 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id q6so8670096ljp.4 for ; Thu, 23 Jul 2020 22:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ILMeiJLuBmTB1VmTjkxwvrY+5pTxuFJbTdHbphPrxTk=; b=R7MpIDSj76I1455TjavXiVEBGUc4HPJpxcHW7N75oAMjdvrJNyrPyghiDanlcPhVYk z6QHWbvJCT8i/+SJsIV9W9bzdfLOO1R9C5+dkW6sf4/ewb6jS6eaZFEm0+By5jWmFA8L noqKZ2KbQv3tznv0aq+NXA28n89LaERVLRKeBxMjTMVVX5H96/Zj9gvbOlpr5M2Iq5G8 Ym3xk4ONG0bXUJdbOoWFzbZD5hLikySdC4U3aaeZYGw+FPXhYNtUnYsbC9ksZQxZNyvM 4RTtM32or4zN3T8C1clCBx0BGkmXNdPSnzOynrcPISPvUHDlaPrePHMdWah0n3ZVZp9t RClg== 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=ILMeiJLuBmTB1VmTjkxwvrY+5pTxuFJbTdHbphPrxTk=; b=kwl04MoFkESk4y5Q5EcAQa1VXcAwHNHmIB93/j1cGAIQ26OwgZ8zrGjQb84zCymKNK 7c+aGY2OV2giSSW0shNl/qr+VT0dxEQ82ZEvjPdI0BWcVwmMAlZ8TQrBCWYMd0zvZnmJ KyFwu+qO7ynfr2CxDDiB+bS7gazb7Mr6y0jKGsQvir69240+iC0oEJ+tZRtllY6YHMD+ 3zRHC3vqYdcSjK/RZU7vN1g0GdoTZmRMoCVcVxltiKnJ14IX6foffIGbTntlRerkJb1w ngqvLbeWOhqbZ/0v5JMZI4ANDfhSSfhl8+fxN/7JMroDHsWGEMMjmm47jA0ZUbFl6m+5 4KvQ== X-Gm-Message-State: AOAM531jvNQ3BLtwA1z4NFXrIycbfZcxyYyBJA1+icG0rHIV8ST5NQ5u +5aDVb8O0/Xhp+AGJZwz+EeFl8rMARMJD/T8N1fYTzkdacQ= X-Google-Smtp-Source: ABdhPJwdsnhdg9BqZ0kxn0jyV7MH5mc+YI3Z7u6MxlFieIecqsMegOFMciwBOKgUtaZQvtfyv2JCAJjs0lmDAt+DRV4= X-Received: by 2002:a2e:99c6:: with SMTP id l6mr3795596ljj.220.1595567057739; Thu, 23 Jul 2020 22:04:17 -0700 (PDT) MIME-Version: 1.0 References: <3c3dd70a-a2f4-42f2-95c3-913c3afe3fb7@www.fastmail.com> In-Reply-To: <3c3dd70a-a2f4-42f2-95c3-913c3afe3fb7@www.fastmail.com> From: Victor Vasiliev Date: Fri, 24 Jul 2020 01:04:06 -0400 Message-ID: To: Martin Thomson Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000b1849805ab28e745" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 05:04:22 -0000 --000000000000b1849805ab28e745 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 23, 2020 at 1:57 AM Martin Thomson wrote: > Thanks for the summary Victor, that really helps frame things. > > There are other differences, I think, so it would be good to make sure > that we've captured all the relevant ones before making a call. And > understanding all the implications of each is important. > > The one that comes to mind is the way that fallbacks work. In HTTP, you > can imagine leaning heavily on the HTTP mechanisms for QUIC upgrade (or T= CP > fallback), like Alt-Svc and so forth. The questions raised regarding > non-uniform support for features are relevant here, so this isn't > completely free. In another scheme, you can code the fallback directly, > even to the point of having it in the API: > connect(quicTransport=3Dquic-transport://..., webSocketTransport=3Dwss://= ...). > In other words, a clean slate means that you have to build the features y= ou > want, but you don't necessarily have to deal with the baggage you might n= ot. > What exactly do you mean by "non-uniform support for features"? It's true that HttpTransport in its default state basically has to defer the protocol choice to the browser, since the JavaScript code has no visibility into the state of the socket pool. I'll note, however, that this is not an inherent property of the HTTP wire protocol itself, but rather just the natural way we would treat this kind of URL by default (which is why I split the two questions below the way I did). You can imagine adding extra options to connect() that would change this as needed. > > I haven't formed an opinion on this yet. I have a few concerns/wrinkles > to add below though. > > On Thu, Jul 23, 2020, at 07:23, Victor Vasiliev wrote: > > I was previously concerned that having to > > implement HPACK/QPACK would be a burden to the Web developers since > > those are more complex than what you=E2=80=99d typically find in a WebS= ocket > > implementation, but now that we have a draft to turn compression off > > , I=E2=80=99m le= ss > > worried about this. > > I think that suggests some additional complexities. You have to implemen= t > all of that stack, and trust that browsers do so as well. As we have > learned, sourcing a new capability like this isn't necessarily free. And > this seems at least on-par with ALPN in terms of operational costs for > server deployments. Maybe it is less of a concern as webtransport > endpoints are the only ones that need upgrading, but I don't see this as = an > easy solution. > That's true, though any HTTP extension of this kind would to some extent rely on ALPS (or some other form of half-RTT settings), since otherwise you have to pay a round-trip penalty by waiting for an indication that the server actually supports ALPS. Overall, I think that between this, Accept-CH reliability draft, and other extensions, we would have to solve the SETTINGS latency problem sooner or later anyways. > > > While on the surface the question here is =E2=80=9Cwhich drafts should = we > > adopt?=E2=80=9D, I would like to break this question down into two laye= rs: > > I think that there is question zero: do we need to pick one set, or do we > need to build all four protocols? > > We have not seen sufficient justification for building four protocols > rather than two, so I'm firmly in the "do less work camp" on this. > I don't believe I've seen any enthusiasm for four protocols so far, which is why I posed the first question as a binary choice. Fortunately, even if more interest becomes apparent down the road, WebTransport is currently structured in a way that we can always add more. > > > 1. Do we want to use the wire format in which we try to build > > minimally on top of QUIC (QuicTransport), or do we base it on HTTP? > > 2. To what extent WebTransport connections act like HTTP connections? > > Do they have https URLs or a dedicated schema? Which HTTP headers do > > and don=E2=80=99t work? > > I think that the answer to the second depends on the first. As much as > possible I would prefer NOT to mint new URI schemes, but that is much > harder if you define a completely new protocol. I think that an importan= t > question to resolve before this (1.5?) is how these connections integrate > into the origin model. I think the "origin model" question is automatically answered by the URI scheme, since that would tell us if WebTransport can be, in principle, same-origin to a Web page. --000000000000b1849805ab28e745 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Jul 23, 2020 at 1:57 AM Martin Th= omson <mt@lowentr= opy.net> wrote:
    Thanks for the summary Victor, that reall= y helps frame things.

    There are other differences, I think, so it would be good to make sure that= we've captured all the relevant ones before making a call.=C2=A0 And u= nderstanding all the implications of each is important.

    The one that comes to mind is the way that fallbacks work.=C2=A0 In HTTP, y= ou can imagine leaning heavily on the HTTP mechanisms for QUIC upgrade (or = TCP fallback), like Alt-Svc and so forth.=C2=A0 The questions raised regard= ing non-uniform support for features are relevant here, so this isn't c= ompletely free.=C2=A0 In another scheme, you can code the fallback directly= , even to the point of having it in the API: connect(quicTransport=3Dquic-t= ransport://..., webSocketTransport=3Dwss://...).=C2=A0 In other words, a cl= ean slate means that you have to build the features you want, but you don&#= 39;t necessarily have to deal with the baggage you might not.

    What exactly do you mean by "non-uniform suppor= t for features"?

    It's true that HttpTrans= port in its default state basically has to defer the protocol choice to the= browser, since the JavaScript code has no visibility into the state of the= socket pool.=C2=A0 I'll note, however, that this is not an=C2=A0inhere= nt property of the HTTP wire protocol itself, but rather just=C2=A0the nat= ural way we would treat this kind of URL by default (which is why I split t= he two questions below the way I did).=C2=A0 You can imagine adding extra o= ptions to connect() that would change this as needed.
    =C2=A0

    I haven't formed an opinion on this yet.=C2=A0 I have a few concerns/wr= inkles to add below though.

    On Thu, Jul 23, 2020, at 07:23, Victor Vasiliev wrote:
    > I was previously concerned that having to
    > implement HPACK/QPACK would be a burden to the Web developers since > those are more complex than what you=E2=80=99d typically find in a Web= Socket
    > implementation, but now that we have a draft to turn compression off <= br> > <https://tools.ietf.org/html/draft-vvv-= httpbis-alps-00>, I=E2=80=99m less
    > worried about this.

    I think that suggests some additional complexities.=C2=A0 You have to imple= ment all of that stack, and trust that browsers do so as well.=C2=A0 As we = have learned, sourcing a new capability like this isn't necessarily fre= e.=C2=A0 And this seems at least on-par with ALPN in terms of operational c= osts for server deployments.=C2=A0 Maybe it is less of a concern as webtran= sport endpoints are the only ones that need upgrading, but I don't see = this as an easy solution.

    That's tr= ue, though any HTTP extension of this kind would to some extent rely on ALP= S (or some other form of half-RTT settings), since otherwise you have to pa= y a round-trip penalty by waiting for an indication that the server actuall= y supports=C2=A0ALPS.=C2=A0 Overall, I think that between this, Accept-CH r= eliability draft, and other extensions, we would have to solve the=C2=A0SET= TINGS latency problem sooner or later anyways.
    =C2=A0

    > While on the surface the question here is =E2=80=9Cwhich drafts should= we
    > adopt?=E2=80=9D, I would like to break this question down into two lay= ers:

    I think that there is question zero: do we need to pick one set, or do we n= eed to build all four protocols?

    We have not seen sufficient justification for building four protocols rathe= r than two, so I'm firmly in the "do less work camp" on this.=

    I don't believe I've seen any = enthusiasm for four protocols so far, which is why I posed the=C2=A0first q= uestion as a binary choice.=C2=A0 Fortunately, even if more interest become= s apparent down the road, WebTransport is currently=C2=A0structured in a wa= y that we can always add more.
    =C2=A0

    >=C2=A0 1. Do we want to use the wire format in which we try to build > minimally on top of QUIC (QuicTransport), or do we base it on HTTP? >=C2=A0 2. To what extent WebTransport connections act like HTTP connect= ions?=C2=A0
    > Do they have https URLs or a dedicated schema?=C2=A0 Which HTTP header= s do
    > and don=E2=80=99t work?

    I think that the answer to the second depends on the first.=C2=A0 As much a= s possible I would prefer NOT to mint new URI schemes, but that is much har= der if you define a completely new protocol.=C2=A0 I think that an importan= t question to resolve before this (1.5?) is how these connections integrate= into the origin model.

    I think the "o= rigin model" question is automatically answered by the URI scheme, sin= ce that would tell us if WebTransport can be, in principle, same-origin to = a Web page.
    --000000000000b1849805ab28e745-- From nobody Thu Jul 23 22:49:08 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F3A3A0C6D for ; Thu, 23 Jul 2020 22:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=ojUcNda0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hOWZ1XK+ 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 w8RLvRoQOO2l for ; Thu, 23 Jul 2020 22:49:04 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C979C3A0C6C for ; Thu, 23 Jul 2020 22:49:04 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E837D5C00A8; Fri, 24 Jul 2020 01:49:03 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 24 Jul 2020 01:49:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=sLk06o8ArdKu+Vwr9kJczu4ET3Mo c1QrPakDyOJ2ce4=; b=ojUcNda0gfdtm6yH9NVJvuabEg0IlsLhmVyaxe/7aBVd 1HMReRTPowYfGC8oRTrTNnG5+RL3GtdQ+j6i1c5u8z56b6OVjf19OxGVqMo49rxD CAxtXEulOzYcPpJGL0ECNhpDdL82HIMlnd6fbs7ItU1K4zPdZgFUbqriBCV5jsyg UBIdTjB1ZgF+EwZotzejP0zhy1/jOCoQl/7eQfFMkqV8HbQ+ANdVQXBbetgLj9PH 3cy679ZQTNJqRmbX1dUfa2GR0Tw8NWxGVmllz7NrB4vcfa1ezhheR4dTc2zDfF2f ZTG5qNOxvLJ2HNW79HADgIhZ09y4DXTyrEu24YQvuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=sLk06o 8ArdKu+Vwr9kJczu4ET3Moc1QrPakDyOJ2ce4=; b=hOWZ1XK+Ylzf1PLfGarOye 0kWYDPOJlgAXVYklrdm7QoQZgR/JJmVSD2kIZpXZqHynrDpiqErrzzcPCxXAsVMc mag+HZtcPbh+Y9h9XE1UlK2LRW5OVit5EgIdwOsm0h/bf63YMRRRqk1v84kxL8Ya fUlH9P5PSyJ3av9dbKyMpNdfTxYKFTsosaAWhHnqBle7KQk0QEfwDZju/xx/UJnS RuGemzi/ew7s+uuRqw/ZF5kQArnLJJXvsTL18DwY/VLc1Iufyu6nPGEEGyljXDJM 8BTkMKSIgRXcwdzuJ5guE+Cha10IOiULuCQrierhSLP+0+Qt9yQxq5TgvZOjGfRA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedvgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 82AD0E00C9; Fri, 24 Jul 2020 01:49:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <4a590d51-396c-4630-aa85-06ca252b4855@www.fastmail.com> In-Reply-To: References: <3c3dd70a-a2f4-42f2-95c3-913c3afe3fb7@www.fastmail.com> Date: Fri, 24 Jul 2020 15:48:41 +1000 From: "Martin Thomson" To: "Victor Vasiliev" Cc: WebTransport Content-Type: text/plain Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 05:49:06 -0000 On Fri, Jul 24, 2020, at 15:04, Victor Vasiliev wrote: > The questions raised regarding non-uniform support for features are relevant here, so this isn't completely free. > > What exactly do you mean by "non-uniform support for features"? Let's say that you like a particular extension to the protocol, but the server doesn't universally implement it across versions. The worse case is where the extension works in one version, but not a protocol that you might otherwise prefer. For instance, DATAGRAM support not being available in HTTP/3. This is just a natural consequence of building protocols up piecemeal. It's not a big deal, but it does tend to happen more with an existing protocol that you build on than a protocol you build from scratch. > I think the "origin model" question is automatically answered by the > URI scheme, since that would tell us if WebTransport can be, in > principle, same-origin to a Web page. I'm not sure that it is necessarily that simple. This gets into the issues that Adam raised about cookies, and there are questions about CORS. It probably makes sense to recognize this as being exempt from CORS preflight on the understanding that support for the protocol implies an acknowledgment that ambient authority is NOT sufficient for authorization, but we also have to consider what state from the target origin is carried across into the WebTransport session. Maybe we don't provide a way to carry cookies, but can we share connections? Or session tickets? I see from Bernard's response that the current thinking is to avoid this by avoiding connection reuse entirely. I'm not yet convinced that this is the right answer. From nobody Fri Jul 24 00:00:52 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061CD3A003C for ; Fri, 24 Jul 2020 00:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxFAyiapNGct for ; Fri, 24 Jul 2020 00:00:50 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 547123A0033 for ; Fri, 24 Jul 2020 00:00:50 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id v15so99091lfg.6 for ; Fri, 24 Jul 2020 00:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sxZBlbgYO58stP5TwGbcdEkvAEsoHqC/ONqiFLxDrDk=; b=V830W8AaSuqxKyyDqtC9vYLEb3HASGDNYe1vxPSrL2a+ZYjJmW2VvkXcnk3qAXl4E+ cNtT6Jz7LV1Pdx2GbFn3j/ElwF17CmDXYY5znHYFgW5LK0qjWbRpa52uD7I3J86vhxU9 BIraDZP8orZW8JewBNbYEIyGFI/hJqMhRuQk2Rq4iNCySIdc2EX8lvc/MQCRLMb2CdKg EjSP11KWatb+mvvo0fukySOqfXw7G/fxkZnZxIrjTqCJN8kkBFN3MuGNnMPk8wvoIa+L dDPy5dpLxi7KlCgcIDrLQWPBDZW/uzqcpWcorJWf8eJH/pWiqGUz/ClCOfzzk5H7jO0i B7dQ== 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=sxZBlbgYO58stP5TwGbcdEkvAEsoHqC/ONqiFLxDrDk=; b=cmPP3EsRNbHgQfAbLpoJwhJkUpPj9NT0RUj/c+n8tSyRiYOvJ2+aoFF5NJYzhHIB7H i1eYRMqgigD3LjAYTByotcAjh7OJzHmGNh1E5oSraYUeX6/O2d5aGx895BkHrpEE/iMQ P0EFTKAgi8MofLhEUmxdfOSgGzJFJS3v7vkIpZAVFZjdjzoPI5n0GXJi0dLjcANusXeH uvp9YgzQAON0S3dsHdMN5dzIzSz4wZPjDdxX9CnFRdO5A3O6W9bdOvIhEmzzI/XNvuuE M5+49h4TuCsHAvzyexdkNWSzA7Tqmdb8uzZVvHttujpMROdbUOLKSTPigqt73ZZlc7r+ MyyQ== X-Gm-Message-State: AOAM532CbJm0nZJcZd1kA3vBF1KBc2sSZej0+YVSghyQWYBAS46nVPMN 2dppEVHdTKU3mkSm8+TnHmz7Gd6CAm2s7Bqabs7DOg== X-Google-Smtp-Source: ABdhPJzZD25oRDCNKneQLmO1X0ZOpgQEmRxMWSlxTP295L3emPL1ILBCZP52uBM2w+1KJAr1GBNGJZ2JA2i7qY7xOCc= X-Received: by 2002:ac2:5338:: with SMTP id f24mr4295959lfh.5.1595574048092; Fri, 24 Jul 2020 00:00:48 -0700 (PDT) MIME-Version: 1.0 References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> In-Reply-To: From: Victor Vasiliev Date: Fri, 24 Jul 2020 03:00:36 -0400 Message-ID: To: Bernard Aboba Cc: Martin Thomson , WebTransport Content-Type: multipart/alternative; boundary="00000000000059f97b05ab2a88b8" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 07:00:52 -0000 --00000000000059f97b05ab2a88b8 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 23, 2020 at 9:42 PM Bernard Aboba wrote: > Martin said: > > "That's a good point. My understanding of the HTTP mappings is that you > can make several "instances" of the WebTransport thing in the one > connection." > > [BA] Here is the current Http3Transport constructor: > > [Exposed =(Window,Worker)]interface Http3Transport { > constructor(DOMString url ); > }; > > > It only takes a url as an argument (like the WebSocket constructor). So > the implication is that invoking the constructor creates a distinct QUIC > connection. But using that QUIC connection, it is possible to create > multiple bi-directional or uni-directional streams or send datagrams in > either direction. So "pooling" or other sharing of an Http3Transport is > already supported to a significant extent. > Http3Transport supports that form of multiplexing using Session IDs: https://tools.ietf.org/html/draft-vvv-webtransport-http3-02#section-4.3. As Virat has pointed out, this helps to cut down on the number of individual connections to an individual server, which is one of HttpTransport's more compelling points. > > Martin said: > "Even if you only have one WebTransport thing, you can still use the same > connection for HTTP and the thing." > > [BA] Note that the Http3Transport constructor doesn't have an optional > QuicTransport object as an argument, so that there's no way to "share" a > QUIC transport between Http3 (as used by say, fetch) and Http3Transport. > > There is a reason why this isn't supported, even though it was something > that seemed quite desirable. HTTP/3 is very specific on how it uses Stream > IDs, so it would be quite tricky to have both the WebTransport and another > API like fetch sharing a QUIC connection. > Stream IDs are indeed a problem for HTTP-based transports, which is one of the reasons we got rid of them in the API draft at some point. Part of this has to do with behavior across proxies, and part of this has to do with accidental information disclosure about different-origin traffic on a shared connection. I've actually filed an issue about this that I want to discuss at the upcoming meeting: https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1 There are also lots of questions of how multiplexing interacts with MAX_STREAM_ID and potential DoS concerns, and I am not sure we actually address those in the draft right now. > On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson wrote: > >> On Fri, Jul 24, 2020, at 04:33, virat tara wrote: >> > For an app that would use both regular HTTP calls and WebTransport, >> > from the server's perspective, won't using HttpTransport instead of a >> > dedicated connection like in QuicTransport help it to reduce the number >> > of active connections/sockets per client? Thus allowing it to serve >> > more distinct clients per server. Particularly for apps that make >> > occasional HTTP calls and heavily rely on a full-duplex protocol for >> > the rest of their working. >> >> That's a good point. My understanding of the HTTP mappings is that you >> can make several "instances" of the WebTransport thing in the one >> connection. Even if you only have one WebTransport thing, you can still >> use the same connection for HTTP and the thing. With a dedicated >> transport, it seems like you just have one. >> >> Of course that one is capable of a lot of concurrency, so you might be >> comfortable with not having multiple sessions, but I can imagine cases for >> sharing different logical contexts that can be split at a gateway. >> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --00000000000059f97b05ab2a88b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Jul 23, 2020 at 9:42 PM Bernard A= boba <bernard.aboba@gmail.com= > wrote:
    Martin said:=C2=A0

    "That's a good point.=C2= =A0 My understanding of the HTTP mappings is that you can make several &quo= t;instances" of the WebTransport thing in the one connection."

    [BA] Here is the current Http3Transport=C2=A0constru= ctor:=C2=A0

    [Exposed=3D(Window,Worker)]
interface Http3Transport {
  constructor<=
/dfn>(DOMString url=
);
};

    It only takes a url as an argument (like = the WebSocket constructor).=C2=A0 So the implication is that invoking the c= onstructor creates a distinct QUIC connection.=C2=A0 But using that QUIC=C2= =A0connection, it is possible to create multiple bi-directional or uni-dire= ctional streams or send datagrams in either direction.=C2=A0 So "pooli= ng" or other sharing of an Http3Transport is already supported to a si= gnificant extent.=C2=A0

    =
    Http3Transport supports that form of multiplexing using Session IDs:= =C2=A0https://tools.ietf.org/html/draft-vvv-webtransport-http3-02#= section-4.3.=C2=A0 As Virat has pointed out, this helps to cut down on = the number of individual connections to an individual server, which is one = of HttpTransport's more compelling points.
    =C2=A0

    Martin said:=C2=A0
    "= Even if you only have one WebTransport thing, you can still use the same co= nnection for HTTP and the thing."=C2=A0

    [BA]= =C2=A0 Note that the Http3Transport=C2=A0 constructor doesn't have an o= ptional QuicTransport object as an argument, so that there's no way to = "share" a QUIC=C2=A0transport between Http3 (as used by say, fetc= h) and Http3Transport.

    There is a reason why this = isn't supported, even though it was something that seemed quite desirab= le. HTTP/3 is very specific on how it uses Stream IDs, so it would be quite= tricky to have both the WebTransport and another API like fetch sharing a = QUIC connection.=C2=A0

    Stream IDs are indeed a problem for HTTP-based transports, which is= one of the reasons we got rid of them in the API draft=C2=A0at some point.= =C2=A0 Part of this has to do with behavior across proxies, and part of thi= s has to do with accidental information disclosure about different-origin t= raffic on a shared connection.=C2=A0 I've actually filed an issue about= this that I want to discuss at the upcoming meeting:=C2=A0https= ://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/issues/1

    There are also lots of questions of how multiplexing= interacts with MAX_STREAM_ID and potential DoS concerns, and I am not sure= we actually address those in the draft right now.
    =C2=A0
    =
    On Thu, Jul 23, 2020 at 4:58 PM Marti= n Thomson <mt@low= entropy.net> wrote:
    On Fri, Jul 24, 2020, at 04:33, virat tara wrote:
    > For an app that would use both regular HTTP calls and WebTransport, > from the server's perspective, won't using HttpTransport inste= ad of a
    > dedicated connection like in QuicTransport help it to reduce the numbe= r
    > of active connections/sockets per client? Thus allowing it to serve > more distinct clients per server. Particularly for apps that make
    > occasional HTTP calls and heavily rely on a full-duplex protocol for <= br> > the rest of their working.

    That's a good point.=C2=A0 My understanding of the HTTP mappings is tha= t you can make several "instances" of the WebTransport thing in t= he one connection.=C2=A0 Even if you only have one WebTransport thing, you = can still use the same connection for HTTP and the thing.=C2=A0 With a dedi= cated transport, it seems like you just have one.=C2=A0

    Of course that one is capable of a lot of concurrency, so you might be comf= ortable with not having multiple sessions, but I can imagine cases for shar= ing different logical contexts that can be split at a gateway.

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --00000000000059f97b05ab2a88b8-- From nobody Fri Jul 24 00:39:14 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6363A0B19 for ; Fri, 24 Jul 2020 00:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZMDCFIgIff7 for ; Fri, 24 Jul 2020 00:39:11 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 E38CD3A0B10 for ; Fri, 24 Jul 2020 00:39:10 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id h22so8996823lji.9 for ; Fri, 24 Jul 2020 00:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iR24vn5OxC04sn72tJ/hu3RP1w3kTU0B7RgW6fS/lPk=; b=EaxUBunFHExVtI4O9OLbEmhGjUMFgJKM0/O4eZnT3Lj8NHksr1Cplw9tHcIJ2oyM1u 0abZC3fHN+vyB3+8tBMvIeF+4CSv6VN2K/aiwReYuLkL7IcVLQyH7xfmMYSbyd0Ph+Ix GdhPQ9uCd10xd0Q64864LzibkFAhcF0CQTYNpfDHFfLVJwqZKUFl4Dh/SwIuCrZnQO2C MfZucnujanOXKVF/GEuu2a4wyUtge46WOCUdVUlxLPbKZ9otNnD9P0vUfiHKKUzNAWgF eelAxSHuIXy1KewUqdxwj1JL7XewkPEjFYZM9LkMI2wHFbKL7TljLuhvD24Y9zT7meHx zTyQ== 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=iR24vn5OxC04sn72tJ/hu3RP1w3kTU0B7RgW6fS/lPk=; b=B38pcDTBAYeYxDBoBkZiv2z4Vt1CJPCZQtWFZ68Ox8DJb0mmHFBjaNUrhO7LLNTEC0 Lf5y8JPl21aJ38Evg2CIGpZKLE0p/k1QEVhPw1tusF09dfmNSZ6XsiF2OZx3zsennEDS RQSpAa428fE3CPqx5p83MqkWagwrcN1B52tLeQA3+SAI6tAAY493PTpftxfNWv+gn9AL cqw3yj20doDvDACM+qzLOm0iYDwcwyQhnqyKXtXheuB+SWFyDc7DzwXIfP7PPO9ZlP3u aDKeASwBF7PWzjIH5HwSN0NyYzxkWTkx5IPP7WW+/0nd+wN7uYYhigC6heM/zrnmjX5e nEDQ== X-Gm-Message-State: AOAM531b/8LmD6lkzXJ7hqHGsy+voFAfO65FhYC8QF0Vj2wV7/amm95a wQnkDangK4lhIHCMEL3M7igVNWgKKZ0cS1jL90EbVz0A X-Google-Smtp-Source: ABdhPJwOVpQdAJmi0yv0Rk343kqHiDBeDUD4i8T9ZN0Eo+fA7To5UjWVsW+/RJpLQFCNUiNA5tZmXF00epFLX0K5vsw= X-Received: by 2002:a2e:9b87:: with SMTP id z7mr4112967lji.80.1595576348472; Fri, 24 Jul 2020 00:39:08 -0700 (PDT) MIME-Version: 1.0 References: <3c3dd70a-a2f4-42f2-95c3-913c3afe3fb7@www.fastmail.com> <4a590d51-396c-4630-aa85-06ca252b4855@www.fastmail.com> In-Reply-To: <4a590d51-396c-4630-aa85-06ca252b4855@www.fastmail.com> From: Victor Vasiliev Date: Fri, 24 Jul 2020 03:38:57 -0400 Message-ID: To: Martin Thomson Cc: WebTransport Content-Type: multipart/alternative; boundary="00000000000076fca605ab2b11e8" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 07:39:13 -0000 --00000000000076fca605ab2b11e8 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 24, 2020 at 1:49 AM Martin Thomson wrote: > On Fri, Jul 24, 2020, at 15:04, Victor Vasiliev wrote: > > The questions raised regarding non-uniform support for features are > relevant here, so this isn't completely free. > > > > What exactly do you mean by "non-uniform support for features"? > > Let's say that you like a particular extension to the protocol, but the > server doesn't universally implement it across versions. The worse case is > where the extension works in one version, but not a protocol that you might > otherwise prefer. For instance, DATAGRAM support not being available in > HTTP/3. > > This is just a natural consequence of building protocols up piecemeal. > It's not a big deal, but it does tend to happen more with an existing > protocol that you build on than a protocol you build from scratch. > I think the draft currently defines DATAGRAM as a requirement for WebTransport over HTTP/3, so the question here would be something among the lines of "what do we do when we have an active HTTP/3 connection in the pool, but it has no WT support?". I agree there's a lot of ambiguity in this space right now, and it kind of exists between protocol space and the API space. > > > I think the "origin model" question is automatically answered by the > > URI scheme, since that would tell us if WebTransport can be, in > > principle, same-origin to a Web page. > > I'm not sure that it is necessarily that simple. This gets into the > issues that Adam raised about cookies, and there are questions about CORS. > It probably makes sense to recognize this as being exempt from CORS > preflight on the understanding that support for the protocol implies an > acknowledgment that ambient authority is NOT sufficient for authorization, > but we also have to consider what state from the target origin is carried > across into the WebTransport session. Maybe we don't provide a way to > carry cookies, but can we share connections? Or session tickets? I see > from Bernard's response that the current thinking is to avoid this by > avoiding connection reuse entirely. I'm not yet convinced that this is the > right answer. > I believe cookies are defined to be bound to a host-port tuple (since they predate the origin model), meaning that the question is mostly just "do we want to send them at all?", because the rules are otherwise clear. Regarding CORS, I agree that a preflight is not necessary, and for what it's worth, WebSocket does not do it already. Sharing connections should probably follow the regular HTTP connection reuse rules, which are nominally defined in RFC 7540 , but also depend on other factors like the credentials mode and probably some other bespoke rules that aren't written down anywhere. Session tickets in general are only bound by SNI, and for 0-RTT, by ALPN; I don't think the behavior there depends on the application protocol in any form. --00000000000076fca605ab2b11e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Fri, Jul 24, 2020 at 1:49 AM Martin Th= omson <mt@lowentropy.net> wr= ote:
    On Fri, Jul 24, 2020, at 15:04, Victor Vasiliev wrote:
    > The questions raised regarding non-uniform support for features are re= levant here, so this isn't completely free.
    >
    > What exactly do you mean by "non-uniform support for features&quo= t;?

    Let's say that you like a particular extension to the protocol, but the= server doesn't universally implement it across versions.=C2=A0 The wor= se case is where the extension works in one version, but not a protocol tha= t you might otherwise prefer.=C2=A0 For instance, DATAGRAM support not bein= g available in HTTP/3.

    This is just a natural consequence of building protocols up piecemeal.=C2= =A0 It's not a big deal, but it does tend to happen more with an existi= ng protocol that you build on than a protocol you build from scratch.

    I think the draft currently defines DATAGRAM= as a requirement for WebTransport over HTTP/3, so the question here would = be something among the lines of "what do we do when we have an active = HTTP/3 connection in the pool, but it has no WT support?".=C2=A0 I agr= ee there's a lot of ambiguity in this space right now, and it kind of e= xists between protocol space and the API space.
    =C2=A0

    > I think the "origin model" question is automatically answere= d by the
    > URI scheme, since that would tell us if WebTransport can be, in
    > principle, same-origin to a Web page.

    I'm not sure that it is necessarily that simple.=C2=A0 This gets into t= he issues that Adam raised about cookies, and there are questions about COR= S.=C2=A0 It probably makes sense to recognize this as being exempt from COR= S preflight on the understanding that support for the protocol implies an a= cknowledgment that ambient authority is NOT sufficient for authorization, b= ut we also have to consider what state from the target origin is carried ac= ross into the WebTransport session.=C2=A0 Maybe we don't provide a way = to carry cookies, but can we share connections?=C2=A0 Or session tickets?= =C2=A0 I see from Bernard's response that the current thinking is to av= oid this by avoiding connection reuse entirely.=C2=A0 I'm not yet convi= nced that this is the right answer.

    I b= elieve cookies are defined to be bound to a host-port tuple (since they pre= date the origin model), meaning that the question is mostly just "do w= e want to send them at all?", because the rules are otherwise clear.
    Regarding CORS, I agree that a=C2=A0preflight is not necessary, an= d for what it's worth, WebSocket does not do it already.
    Shar= ing connections should probably follow the regular HTTP connection reuse ru= les, which are nominally defined in RFC 7540, but also depend on other factors like=C2= =A0the credentials mode=C2=A0and probably some other bespoke rules tha= t aren't written down anywhere.
    Session tickets in general ar= e only bound by SNI, and for 0-RTT, by ALPN; I don't think the behavior= there depends on the application protocol in any form.
    --00000000000076fca605ab2b11e8-- From nobody Fri Jul 24 04:30:43 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8FE3A0EF6 for ; Fri, 24 Jul 2020 04:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 cl2lMlkU87tM for ; Fri, 24 Jul 2020 04:30:39 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 51C943A0EDD for ; Fri, 24 Jul 2020 04:30:39 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id p6so2823285uaq.12 for ; Fri, 24 Jul 2020 04:30:39 -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=cyhoZSo4N5IwXRXCT1XhYnBIkwRJlDnDnwJPp9J4AlI=; b=e4h7GOtk3A3kJdJP+gdizi0mK5IJ30UUbyvOIrsB+XQRfDbreP6ot73Lbas6rlJq01 8u+k+68x69mXiutPhcOlKOh7q6dPmRShO0jCAQKpaFwRsoXR97YFSMCTv0xlpF9eqZDJ AGWqkF74ddretteRYqgwM+RxkfH9gMJgrFkbnIi2E/7ZsPFnSntJGKWXBoU6g1P59g57 XKdrLh4Vq6pcNYQtL6pV+F2vY1vfj4BjrLrrUf+kMIsoFodlIbHsEhxOFicTvOVsy6pW as0XCusB7XyNsrLXWtZ8JF3Ev7sDFfrmh2ST6Pk6HoQ3s/WE3ce5UkkNtcvJJTJP0t9T U9/Q== 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=cyhoZSo4N5IwXRXCT1XhYnBIkwRJlDnDnwJPp9J4AlI=; b=OziSlA3S12b9jIZP9BOvqJrYicm2vls5YGBk8+L4qb1y1Q4876JxSbwQqJ1/Bphszf nyx5fHI1DICYgY8z8g9I0oW5GAdSZyVJeoq8asiN18tLIy2VfbOwGJquoiWmu1S6F/CL CpE1m/udzTOuU9EiPVene0woAdanhaSFl1aB3lSobY8dglhjKUci+U7A4nfpSMM2fXF5 JP0ZG69RfTCCV0GOoFHEEbcmoRxy4eVMu0XrbKFsIq8XVWI297Zob501NGp61nwU/0Hl k9kUSHVRTTioEvbvbUBlVyLGqeVV+xpsSsqv5BqC73eH5cPI/HyX/2RakPDvs66c0TKb hp+g== X-Gm-Message-State: AOAM531sZlG5q6Dz24sp4p0svfxydg7Yox8rFxwXSseu3MMEOvSTEHuW LkvoxNjPwO8Q7V0E/Jt2Q85kV3R/porxNJvDVhk= X-Google-Smtp-Source: ABdhPJx+O1iS+0YbS8L2Diytafsuz0IPbEOjfuN70hqBsSRvRpzATEYlfwCLiaxjTcV0GMVPeaok9veqDQj6DsOunmo= X-Received: by 2002:ab0:29cb:: with SMTP id i11mr7640323uaq.12.1595590237988; Fri, 24 Jul 2020 04:30:37 -0700 (PDT) MIME-Version: 1.0 References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> In-Reply-To: From: virat tara Date: Fri, 24 Jul 2020 17:00:24 +0530 Message-ID: To: Bernard Aboba Cc: Martin Thomson , WebTransport Content-Type: multipart/alternative; boundary="00000000000057ac7505ab2e4dc0" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 11:30:42 -0000 --00000000000057ac7505ab2e4dc0 Content-Type: text/plain; charset="UTF-8" Hi Bernard, > Note that the Http3Transport constructor doesn't have an optional > QuicTransport object as an argument, so that there's no way to "share" a > QUIC transport between Http3 (as used by say, fetch) and Http3Transport. > I got the impression that HTTP/3 calls like fetch and Http3Transport will be able to share a connection from draft-vvv-webtransport-http3-02#section-1 where it says "Using the mechanism described here, multiple Http3Transport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection". The ability to share a QUIC connection between HTTP3 (e.g. fetch) and > WebTransport (via WebTransport API) has come up from time to time. Do you > have a use case where this would be valuable? > An example would be an app where full-duplex communication is required only at a particular step of the user flow (ex. taxi booking or food ordering application), like at the time of live location sharing or chat support, but the rest of the functionality requires only client to server API calls. Some of these actions can be simultaneously performed by the user like live location sharing + browsing through the app and thus making some fetch calls. One can argue that the fetch calls being stateless can be converted into events to make them compatible with WebTransport. I think that's not a simple decision to make once you have built up an application and later on decide to incorporate a small feature that requires full duplex communication on the same server. One can always resort to HTTP Long Polling in such cases and I think this is one of the main reasons long polling is still in use and not obsolete. RFC 8441 would have made it obsolete but it is yet to be rolled out on major browsers. On Fri, Jul 24, 2020 at 7:12 AM Bernard Aboba wrote: > Martin said: > > "That's a good point. My understanding of the HTTP mappings is that you > can make several "instances" of the WebTransport thing in the one > connection." > > [BA] Here is the current Http3Transport constructor: > > [Exposed =(Window,Worker)]interface Http3Transport { > constructor(DOMString url ); > }; > > > It only takes a url as an argument (like the WebSocket constructor). So > the implication is that invoking the constructor creates a distinct QUIC > connection. But using that QUIC connection, it is possible to create > multiple bi-directional or uni-directional streams or send datagrams in > either direction. So "pooling" or other sharing of an Http3Transport is > already supported to a significant extent. > > Martin said: > "Even if you only have one WebTransport thing, you can still use the same > connection for HTTP and the thing." > > [BA] Note that the Http3Transport constructor doesn't have an optional > QuicTransport object as an argument, so that there's no way to "share" a > QUIC transport between Http3 (as used by say, fetch) and Http3Transport. > > There is a reason why this isn't supported, even though it was something > that seemed quite desirable. HTTP/3 is very specific on how it uses Stream > IDs, so it would be quite tricky to have both the WebTransport and another > API like fetch sharing a QUIC connection. > > > > On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson wrote: > >> On Fri, Jul 24, 2020, at 04:33, virat tara wrote: >> > For an app that would use both regular HTTP calls and WebTransport, >> > from the server's perspective, won't using HttpTransport instead of a >> > dedicated connection like in QuicTransport help it to reduce the number >> > of active connections/sockets per client? Thus allowing it to serve >> > more distinct clients per server. Particularly for apps that make >> > occasional HTTP calls and heavily rely on a full-duplex protocol for >> > the rest of their working. >> >> That's a good point. My understanding of the HTTP mappings is that you >> can make several "instances" of the WebTransport thing in the one >> connection. Even if you only have one WebTransport thing, you can still >> use the same connection for HTTP and the thing. With a dedicated >> transport, it seems like you just have one. >> >> Of course that one is capable of a lot of concurrency, so you might be >> comfortable with not having multiple sessions, but I can imagine cases for >> sharing different logical contexts that can be split at a gateway. >> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --00000000000057ac7505ab2e4dc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Bernard,
    =C2=A0
    Note that= the Http3Transport=C2=A0 constructor doesn't have an optional QuicTran= sport object as an argument, so that there's no way to "share"= ; a QUIC=C2=A0transport between Http3 (as used by say, fetch) and Http3Tran= sport.

    The ability to share a QUIC connection between HTTP3= (e.g. fetch) and WebTransport (via WebTransport API) has come up from time= to time. Do you have a use case where this would be valuable?

    An example would be an app where full-duplex commun= ication is required only at a particular step of the user flow (ex. taxi bo= oking or food ordering application), like at the time of live location shar= ing or chat support, but the rest of the functionality requires only client= to server API calls. Some of these actions can be simultaneously performed= by the user like live location sharing=C2=A0+ browsing through the app and= thus making some fetch calls.


    On Fri, Jul 24, 2020 at 7:12 AM Bernard Ab= oba <bernar= d.aboba@gmail.com> wrote:
    Martin said:=C2=A0

    &q= uot;That's a good point.=C2=A0 My understanding of the HTTP mappings is= that you can make several "instances" of the WebTransport thing = in the one connection."

    [BA] Here is the curr= ent Http3Transport=C2=A0constructor:=C2=A0

    [Exposed=3D(Window,Worker)]
interface Http3Transport {
  constructor(DOMString url<=
a href=3D"https://wicg.github.io/web-transport/#dom-http3transport-construc=
tor-url-url" style=3D"color:white;text-decoration-line:none;border:none;pad=
ding:0px 1px;width:1.5em;height:1.5em;text-align:center;opacity:0;backgroun=
d-color:gray;font-style:normal" target=3D"_blank">);
};

    It only takes a url as an argument (like = the WebSocket constructor).=C2=A0 So the implication is that invoking the c= onstructor creates a distinct QUIC connection.=C2=A0 But using that QUIC=C2= =A0connection, it is possible to create multiple bi-directional or uni-dire= ctional streams or send datagrams in either direction.=C2=A0 So "pooli= ng" or other sharing of an Http3Transport is already supported to a si= gnificant extent.=C2=A0

    Martin said:=C2=A0
    "Even if you only have one WebTransport thing, you can still use th= e same connection for HTTP and the thing."=C2=A0

    <= div>[BA]=C2=A0 Note that the Http3Transport=C2=A0 constructor doesn't h= ave an optional QuicTransport object as an argument, so that there's no= way to "share" a QUIC=C2=A0transport between Http3 (as used by s= ay, fetch) and Http3Transport.

    There is a reason w= hy this isn't supported, even though it was something that seemed quite= desirable. HTTP/3 is very specific on how it uses Stream IDs, so it would = be quite tricky to have both the WebTransport and another API like fetch sh= aring a QUIC connection.=C2=A0


    =

    On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson <mt@lowentropy.net> = wrote:
    On Fri, Jul 24, 2020, at 04:33, virat tara= wrote:
    > For an app that would use both regular HTTP calls and WebTransport, > from the server's perspective, won't using HttpTransport inste= ad of a
    > dedicated connection like in QuicTransport help it to reduce the numbe= r
    > of active connections/sockets per client? Thus allowing it to serve > more distinct clients per server. Particularly for apps that make
    > occasional HTTP calls and heavily rely on a full-duplex protocol for <= br> > the rest of their working.

    That's a good point.=C2=A0 My understanding of the HTTP mappings is tha= t you can make several "instances" of the WebTransport thing in t= he one connection.=C2=A0 Even if you only have one WebTransport thing, you = can still use the same connection for HTTP and the thing.=C2=A0 With a dedi= cated transport, it seems like you just have one.=C2=A0

    Of course that one is capable of a lot of concurrency, so you might be comf= ortable with not having multiple sessions, but I can imagine cases for shar= ing different logical contexts that can be split at a gateway.

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --00000000000057ac7505ab2e4dc0-- From nobody Sat Jul 25 07:56:28 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0B3A09B3 for ; Sat, 25 Jul 2020 07:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 mjgO5Bv_UCx9 for ; Sat, 25 Jul 2020 07:56:25 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 CEAF63A0AB1 for ; Sat, 25 Jul 2020 07:56:24 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id i19so6715560lfj.8 for ; Sat, 25 Jul 2020 07:56:24 -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=x+nkbdHCMhoDky+mq8eRCZeyQy/K+V4G4WXonGR9S4E=; b=Nkm7StFaoSXGdIIxECriVTrpwGoJgpQ51n2FHJE2qQKj+5oSnk6IzmDnP9nFf4sauD NnoBkpyculN3WYqYaGdHyx7BrwyIwcTw9MJ37NaPGYwtzn08/vDQUyvmLB3bnK8k7cee 9VestQ2fC9oMbmlgLSbxkQF+3EbRT8VeJjMkBekoqO6OUk7QK3cXD+SmAYR7ux8NSsWB hcgWNK1E51DfIcZBS+aW1A4eaG1NztHeWj22WxbHbeLeUldS3iACb/N2WVTUkoOGzkyy mScuhSBQNwq0D6LZz0KaEOK9ff6w7hS9fzv5qnxhJSa5er9MvIONgyS2vWERzdiv6bI/ 5+Hw== 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=x+nkbdHCMhoDky+mq8eRCZeyQy/K+V4G4WXonGR9S4E=; b=gVJ0DCCJJ5XmbcNyrqSspDPmIGdyUH8yc0VwK1jR+TDvqkdQuMsNXd8FAM0AOkwAwb BDXud8q8uCLhqWeYy46PkzoyaceR9DRSHDHRTzkg4fSgpuebn/mIccokQ12Kws3E8WWw irW1mUBEbJnpN40WSYxSx9TGwP1tU50K8wdowF5D7SZBj/FNadLKjZ98bmEbkLiUvzer iwB5+nmfbb66RUdyNtMyvwQo3t7o5yqjSn/YsX1IRKtks+RCLziJquzXNBKiY3m4IjCN /MfvxSUQP6vlhYuAjzgwG1XQnZxl6sbSbPL6aqBocT8DCdPSfZ4vN/udCVpxaYK+PHld pzug== X-Gm-Message-State: AOAM530Yo0jv+G9MMih4J2bAiiovlK/FONemHdg6P2u+zNrnNZzDc6+8 CcXLx+B3yqKEVyEmkrCQALGjrppV6UhtQWsmZTsXNtdbEqE= X-Google-Smtp-Source: ABdhPJyByVxGi6nGtm4dMPil2iCYzmkJ8X9R7iANK9SLlhMj+pRzG9YjxG1907qs+ziw9k4xoNZDkSnUDKDaGuqLZOw= X-Received: by 2002:ac2:4144:: with SMTP id c4mr7569591lfi.118.1595688982793; Sat, 25 Jul 2020 07:56:22 -0700 (PDT) MIME-Version: 1.0 References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> <3a7c95f9-53cf-4d19-958b-5b4a8eed16f7@www.fastmail.com> In-Reply-To: <3a7c95f9-53cf-4d19-958b-5b4a8eed16f7@www.fastmail.com> From: Bernard Aboba Date: Sat, 25 Jul 2020 07:56:11 -0700 Message-ID: To: Martin Thomson Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000fdd53805ab454a5a" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 14:56:27 -0000 --000000000000fdd53805ab454a5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Martin said: "How do you go from URL to a single connection? fetch takes a single URL too, but those routinely use existing connections (in all protocol versions). I also don't see the BlahTransport as having any inherent 1-1 mapping with connections. If that is the case for Http[N]Transport, I would regard that as a design error." [BA] Here is the text from Section 14.2.1 (Http3Transport) : " 1. Either establish an HTTP/3 connection or reuse an existing HTTP/3 connection to the host specificed by the url, as specified in [WEB-TRANSPORT-HTTP3] . 2. If there is no such HTTP/3 connection to reuse and the establishment of a new HTTP/3 connection, set transport=E2=80=99s [[WebTransportState]] internal slot to "failed" and abort these steps." So there is support for re-use, although it's not clear whether "reuse an HTTP/3 connection" means to reuse a connection on which an Http3Transport has been established, or whether any HTTP/3 connection to the same host can be reused, enabling sharing between fetch and Http3Transport (or maybe even with a QuicTransport). I have filed an issue to clarify this: https://github.com/WICG/web-transport/issues/128 Note that in contrast, Section 8.2 (QuicTransport constructor) says: "Establish a QUIC connection to the address identified by parsedURL followi= ng the procedures in [WEB-TRANSPORT-QUIC] section 3 and using clientOrigin as the "origin of the client" referenced in section 3.2.1. While establishing the connection, follow all of the parameters specified in the options ." So for QuicTransport there are no checks whether a QUIC connection has already been established. So there is no support for sharing of connections between QuicTransports. IMHO, it would be useful to think through the pooling/sharing use cases to make sure that we understand the requirements. On Thu, Jul 23, 2020 at 7:20 PM Martin Thomson wrote: > On Fri, Jul 24, 2020, at 11:42, Bernard Aboba wrote: > > It only takes a url as an argument (like the WebSocket constructor). > > So the implication is that invoking the constructor creates a distinct > > QUIC connection. > > How do you go from URL to a single connection? fetch takes a single URL > too, but those routinely use existing connections (in all protocol > versions). > > I also don't see the BlahTransport as having any inherent 1-1 mapping wit= h > connections. If that is the case for Http[N]Transport, I would regard th= at > as a design error. > > > [BA] Note that the Http3Transport constructor doesn't have an > > optional QuicTransport object as an argument, so that there's no way to > > "share" a QUIC transport between Http3 (as used by say, fetch) and > > Http3Transport. > > Again, how did you get there? I realize that there might be reasons why > you might want to avoid sharing, like the rules we have for font fetching= , > but it doesn't naturally follow that you need a new connection for this. > > > There is a reason why this isn't supported, even though it was > > something that seemed quite desirable. HTTP/3 is very specific on how > > it uses Stream IDs, so it would be quite tricky to have both the > > WebTransport and another API like fetch sharing a QUIC connection. > > Now we're getting somewhere. I agree that getting access to a > bidirectional stream in HTTP/3 is tricky (and a unidirectional stream in > HTTP/2 trickier), but surely these are spelling problems, not fundamental > barriers to multiplexing. > --000000000000fdd53805ab454a5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Martin said:=C2=A0

    "How do you go = from URL to a single connection?=C2=A0 fetch takes a single URL too, but th= ose routinely use existing connections (in all protocol versions).
    I also don't see the BlahTransport as having any inherent 1-1 mapping = with connections.=C2=A0 If that is the case for Http[N]Transport, I would r= egard that as a design error."

    [BA] Here is the tex= t from Section 14.2.1 (Http3Transport):

    &q= uot;
    https://github.com/WICG/web-transport/issues/1= 28

    Note that in contrast,=C2=A0Section 8.2 (QuicTransp= ort constructor)=C2=A0=C2=A0says:=C2=A0

    "Es= tablish a QUIC connection to the address identified by=C2=A0parsedURL=C2=A0following the procedures in=C2=A0[WEB-TR= ANSPORT-QUIC]=C2=A0section 3 and using=C2=A0clientOrigin=C2=A0as = the "origin of the client" referenced in section 3.2.1. While est= ablishing the connection, follow all of the parameters specified in the=C2= =A0options."

    <= span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:medium">So = for QuicTransport there are no checks whether a QUIC connection has already= been established. So there is no support for sharing of connections betwee= n QuicTransports.=C2=A0

    IMHO, it would be useful to think = through the pooling/sharing use cases to make sure that we understand the r= equirements.

    On Thu, Jul 23, 2020 at 7:20 PM Martin Thomson <= ;mt@lowentropy.net> wrote:
    <= /div>
    On Fri, Jul 24, 2020= , at 11:42, Bernard Aboba wrote:
    > It only takes a url as an argument (like the WebSocket constructor).= =C2=A0
    > So the implication is that invoking the constructor creates a distinct=
    > QUIC connection.=C2=A0

    How do you go from URL to a single connection?=C2=A0 fetch takes a single U= RL too, but those routinely use existing connections (in all protocol versi= ons).

    I also don't see the BlahTransport as having any inherent 1-1 mapping w= ith connections.=C2=A0 If that is the case for Http[N]Transport, I would re= gard that as a design error.

    > [BA]=C2=A0 Note that the Http3Transport=C2=A0 constructor doesn't = have an
    > optional QuicTransport object as an argument, so that there's no w= ay to
    > "share" a QUIC transport between Http3 (as used by say, fetc= h) and
    > Http3Transport.

    Again, how did you get there?=C2=A0 I realize that there might be reasons w= hy you might want to avoid sharing, like the rules we have for font fetchin= g, but it doesn't naturally follow that you need a new connection for t= his.

    > There is a reason why this isn't supported, even though it was > something that seemed quite desirable. HTTP/3 is very specific on how =
    > it uses Stream IDs, so it would be quite tricky to have both the
    > WebTransport and another API like fetch sharing a QUIC connection.
    Now we're getting somewhere.=C2=A0 I agree that getting access to a bid= irectional stream in HTTP/3 is tricky (and a unidirectional stream in HTTP/= 2 trickier), but surely these are spelling problems, not fundamental barrie= rs to multiplexing.
    --000000000000fdd53805ab454a5a-- From nobody Sat Jul 25 08:40:38 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5CF3A0A94 for ; Sat, 25 Jul 2020 08:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 swoOudDnInYz for ; Sat, 25 Jul 2020 08:40:36 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 CBD273A0A3B for ; Sat, 25 Jul 2020 08:40:35 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id d17so12905327ljl.3 for ; Sat, 25 Jul 2020 08:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sE3Mo0mTWo8wqm7gi253GDYBA9JJAiJdEN5yuzHMua0=; b=CVGNyd4soPLhrj57pGCrT3PzxLRYVtM9eH/wXWGC7vKhASTeA0I2XBW9gaCUz95fhv lUzpTNZ0LzNTPqFRk0dbfVOBMZnjgjbCZFfh21gtN/iaWZtewPFkai4qOXx/6QBFVUn+ uDDrGBVy6CCWbCpNz2Tynf7HiXdFK936+MbVdbfjjF3YMfOjlYRXtgWwd8bO8U/6/yp+ vgid8ZqJkW+gqe0Yzc61vp0mTDSQcx/wD8Z6KSefif+mSPDqwB1gx7Gsyip4jnz5vGmb RbUBbsOtHO/sIOjqE6fuJMw+Vr7/wtZQlp7uMIDAnqpjT3lKVn0EyFdBbHB1EnzKT+YH xpeQ== 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; bh=sE3Mo0mTWo8wqm7gi253GDYBA9JJAiJdEN5yuzHMua0=; b=MdtaAJzHydE2N3j0t9y5lZMNwpBtHTTDnZgBjL2pyo5jHf/xGZx3o5yhBUaFt+JIM1 HU/1S2MoYPQ1Qvn/o2B9mok0pq4sXa2ZbZvKTSpzoJrZdOOJB9dsbjTwTQOjzbs0ABI7 iKNsInjvmwriSN25GsSmQkrEKuG4GAkvIueco1HjRjKkY67R7UFzkAYbnQKJOY2pUtgd aVnJ9S5KbZ83SJDtnsl5Fh2xm/WAGNDasM73FVvx8Bpy7zkAnGAkRiYCXV3U5jbs8B3C XvUzqvJF5RXOCUyWoWOeyCxJqfHKfQ20ULWYL2vlNzERSqsNB+cVx0hcBOXm348fdxlr pwkQ== X-Gm-Message-State: AOAM532gVDs+s2bqfIQvkRyUc/kgRZvEdbZjJ6yVRu9UsUai8kytnwEl waHYcnkXjy6HmvrMJ8X74omHrfuSgNioUyBRsaGfgCl3lN0= X-Google-Smtp-Source: ABdhPJxbp/WNEJw0lKDBYusQ+PmMmX07CqKRHSSeESPLacSMUsuCRfRs+3+ixyAMeujjGmsoq0UJyBknHhZPFH3C7Cc= X-Received: by 2002:a2e:8296:: with SMTP id y22mr6731674ljg.238.1595691633393; Sat, 25 Jul 2020 08:40:33 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Sat, 25 Jul 2020 08:40:22 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000fac6a305ab45e814" Archived-At: Subject: [Webtransport] Does WebTransport need a reliable, in-order message abstraction? (fwd) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 15:40:38 -0000 --000000000000fac6a305ab45e814 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For some reason this message did not make it to the list. ---------- Forwarded message ---------- From: Alan Frindell To: Webtransport Cc: Bcc: Date: Fri, 24 Jul 2020 21:30:45 +0000 Subject: Does WebTransport need a reliable, in-order message abstraction? I was reviewing the WebSocket specification, and realized there is a gap that is not currently covered in the overview of WebTransport: reliable, in-order messages. The three ways to send messages in WebTransport are: 1) message per datagram, which is unreliable and unordered (and has a lower maximum size than WebSockets) 2) message per stream, which is reliable but not ordered 3) multiple messages per stream, which is reliable and ordered, but not framed A developer either needs to implement their own framing layer on top of a WebTransport stream (perhaps WebSocket over WebTransport?), or use message per stream and handle buffering and ordering of messages at a higher layer. Is replacing WebSockets with WebTransport one of our goals? If so, I think we need to address the gap by adding this abstraction. If not, we should explicitly mention that this abstraction doesn=E2=80=99t exist, and instruc= t developers to use WebSocket instead. -Alan --000000000000fac6a305ab45e814 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    For some reason this message did not make it to the list.= =C2=A0

    ---------- Forwarded message ----------
    Fr= om:=C2=A0Alan Frindell <afrind@fb.com>
    To:=C2=A0Webtransport <webtransport-bounces@ietf.org= >
    Cc:=C2=A0
    Bcc:=C2=A0
    Date:=C2=A0Fri, 24 Jul 2020 21:30:45= +0000
    Subject:=C2=A0Does WebTransport need a reliable, in-order message= abstraction?


    I was reviewing the WebSocket specification, and realized th= ere is a gap that is not currently covered in the overview of WebTransport:= reliable, in-order messages.

    =C2=A0

    The three ways to send messages = in WebTransport are:

    =C2=A0

    1) message per datagram, which is unrelia= ble and unordered (and has a lower maximum size than WebSockets)<= /u>

    2) mess= age per stream, which is reliable but not ordered

    <= p class=3D"MsoNormal">3) multiple messages p= er stream, which is reliable and ordered, but not framed

    =C2=A0

    A dev= eloper either needs to implement their own framing layer on top of a WebTra= nsport stream (perhaps WebSocket over WebTransport?), or use message per st= ream and handle buffering and ordering of messages at a higher layer.

    =C2=A0

    Is replacing WebSockets with WebTransport one of our goals?=C2=A0 I= f so, I think we need to address the gap by adding this abstraction.=C2=A0 = If not, we should explicitly mention that this abstraction doesn=E2=80=99t = exist, and instruct developers to use WebSocket instead.

    =C2=A0

    -Alan=

    --000000000000fac6a305ab45e814-- From nobody Sat Jul 25 09:11:01 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33CD3A0C0F for ; Sat, 25 Jul 2020 09:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 OKT9MSn9xRZd for ; Sat, 25 Jul 2020 09:10:58 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 E6B2D3A0C0D for ; Sat, 25 Jul 2020 09:10:57 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id a27so3470810ljn.8 for ; Sat, 25 Jul 2020 09:10:57 -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=HaPBUTMa5dDhMjmjuQewXnd6DWa9cxc5KO0p6TA5L9E=; b=NwQGlms+cLGunAIBlm/6SEv4yn7J2b1ofFLs7p54k/fkadqk/gHiZrVHfYYW+Xia4O 7YKsttkRxDOgyFsSD+CBHDFGIMhQCLqLBt11XqCvOVwAd1pPiQJIZ2rMRT0NTA3M/Ney /z6e2sIi41tG4qjLh1kHck042yHfpkbT4LR8Ay4NYkndgqyv2ZQyDHxCO5LSmb4/TPvG mDeSiTvtZHZv3BUA9uAwl4ZfoGb3Gf7hISXPMjlEwbWuWbvaP7PJDjIZ2nh3uAm2qp4P gJ/fQs4dXqwaAqXAxiBrgEoSNecfbbp6z1FWLpq25KcUClWAdJ7PLb50g7LemefPxRxn mFLQ== 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=HaPBUTMa5dDhMjmjuQewXnd6DWa9cxc5KO0p6TA5L9E=; b=CpB5fqftQ3Eva9xUDt3aCoFA/eoBId1mJlTqObvyJwzR8CNH3EC41vdd0CH2QaLiKF LwZ/oipWKcE+Z5ARlpW8TXgz+XYy4dKu3aX9mp3YSNqqXAqjNjVCkEWvAK2PyuhMIuNj 1J3oHcmW8JxtOu/G7DuLB8I6ZZXbjVLKZTEvr3vQY74lsZQHeP1DM85vVHAbJINJDvWI OAbuPFlDROLDE2HIZMSKqje1sKXGR85ZtBo96Y3GhZno5Lofgo3vhtd0zs+wRrP22TAj 0WjFxjKf791PrfqGu5di5mxCweR/5iaLfft4G2A6Sef05DrmgpdeJhyVBS+p7E4gWTwR ihrQ== X-Gm-Message-State: AOAM533ujw7uZ55hZM6gjt9reb+91lG7Myuz/4MPgwCoFr4oJOE+p6N2 i7+2/6omjNVgqIFQ3T8f4T2gcCwgG+Yu2kqIAYo= X-Google-Smtp-Source: ABdhPJzIxmSiy/exlpMJAK2CqUWUN1n1paCpzK32QIn9EKFzBx/OAoDHBDJNmmYdqdCgs9vc77jmU5EUK2IlbaZEiEc= X-Received: by 2002:a2e:89cc:: with SMTP id c12mr6861236ljk.187.1595693455824; Sat, 25 Jul 2020 09:10:55 -0700 (PDT) MIME-Version: 1.0 References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> In-Reply-To: From: Bernard Aboba Date: Sat, 25 Jul 2020 09:10:44 -0700 Message-ID: To: virat tara Cc: WebTransport Content-Type: multipart/alternative; boundary="0000000000009ada5e05ab465546" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 16:11:01 -0000 --0000000000009ada5e05ab465546 Content-Type: text/plain; charset="UTF-8" Virat said: "I got the impression that HTTP/3 calls like fetch and Http3Transport will be able to share a connection from draft-vvv-webtransport-http3-02#section-1 where it says "Using the mechanism described here, multiple Http3Transport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection". [BA] The WebTransport API spec seems to imply some (or maybe all) of this, but there isn't any implementation experience AFAIK. "An example would be an app where full-duplex communication is required only at a particular step of the user flow (ex. taxi booking or food ordering application), like at the time of live location sharing or chat support, but the rest of the functionality requires only client to server API calls. Some of these actions can be simultaneously performed by the user like live location sharing + browsing through the app and thus making some fetch calls." [BA] Question: In this use case, is there an interaction between HTTP/3 traffic and WebTransport traffic? For example, in the RIPT BOF there were examples shown where an HTTP/3 Request elicited an HTTP/3 Response as well as HTTP/3 datagram traffic from server to client. The idea was to enable SIP-like exchanges to occur within HTTP/3 so as to enable calling. This would enable the taxi booking or food ordering application to allow the user to talk to the taxi driver or submit their food order in a voice call, using a single HTTP/3 Connection. On Fri, Jul 24, 2020 at 4:30 AM virat tara wrote: > Hi Bernard, > > >> Note that the Http3Transport constructor doesn't have an optional >> QuicTransport object as an argument, so that there's no way to "share" a >> QUIC transport between Http3 (as used by say, fetch) and Http3Transport. >> > > I got the impression that HTTP/3 calls like fetch and Http3Transport will > be able to share a connection from > draft-vvv-webtransport-http3-02#section-1 > where > it says "Using the mechanism described here, multiple Http3Transport > instances can be multiplexed simultaneously with regular HTTP traffic on > the same HTTP/3 connection". > > The ability to share a QUIC connection between HTTP3 (e.g. fetch) and >> WebTransport (via WebTransport API) has come up from time to time. Do you >> have a use case where this would be valuable? >> > > An example would be an app where full-duplex communication is required > only at a particular step of the user flow (ex. taxi booking or food > ordering application), like at the time of live location sharing or chat > support, but the rest of the functionality requires only client to server > API calls. Some of these actions can be simultaneously performed by the > user like live location sharing + browsing through the app and thus making > some fetch calls. > > One can argue that the fetch calls being stateless can be converted > into events to make them compatible with WebTransport. I think that's not a > simple decision to make once you have built up an application and later on > decide to incorporate a small feature that requires full duplex > communication on the same server. One can always resort to HTTP Long > Polling in such cases and I think this is one of the main reasons long > polling is still in use and not obsolete. RFC 8441 > would have made it obsolete but it > is yet to be rolled out on major browsers. > > On Fri, Jul 24, 2020 at 7:12 AM Bernard Aboba > wrote: > >> Martin said: >> >> "That's a good point. My understanding of the HTTP mappings is that you >> can make several "instances" of the WebTransport thing in the one >> connection." >> >> [BA] Here is the current Http3Transport constructor: >> >> [Exposed =(Window,Worker)]interface Http3Transport { >> constructor(DOMString url ); >> }; >> >> >> It only takes a url as an argument (like the WebSocket constructor). So >> the implication is that invoking the constructor creates a distinct QUIC >> connection. But using that QUIC connection, it is possible to create >> multiple bi-directional or uni-directional streams or send datagrams in >> either direction. So "pooling" or other sharing of an Http3Transport is >> already supported to a significant extent. >> >> Martin said: >> "Even if you only have one WebTransport thing, you can still use the same >> connection for HTTP and the thing." >> >> [BA] Note that the Http3Transport constructor doesn't have an optional >> QuicTransport object as an argument, so that there's no way to "share" a >> QUIC transport between Http3 (as used by say, fetch) and Http3Transport. >> >> There is a reason why this isn't supported, even though it was something >> that seemed quite desirable. HTTP/3 is very specific on how it uses Stream >> IDs, so it would be quite tricky to have both the WebTransport and another >> API like fetch sharing a QUIC connection. >> >> >> >> On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson wrote: >> >>> On Fri, Jul 24, 2020, at 04:33, virat tara wrote: >>> > For an app that would use both regular HTTP calls and WebTransport, >>> > from the server's perspective, won't using HttpTransport instead of a >>> > dedicated connection like in QuicTransport help it to reduce the >>> number >>> > of active connections/sockets per client? Thus allowing it to serve >>> > more distinct clients per server. Particularly for apps that make >>> > occasional HTTP calls and heavily rely on a full-duplex protocol for >>> > the rest of their working. >>> >>> That's a good point. My understanding of the HTTP mappings is that you >>> can make several "instances" of the WebTransport thing in the one >>> connection. Even if you only have one WebTransport thing, you can still >>> use the same connection for HTTP and the thing. With a dedicated >>> transport, it seems like you just have one. >>> >>> Of course that one is capable of a lot of concurrency, so you might be >>> comfortable with not having multiple sessions, but I can imagine cases for >>> sharing different logical contexts that can be split at a gateway. >>> >>> -- >>> Webtransport mailing list >>> Webtransport@ietf.org >>> https://www.ietf.org/mailman/listinfo/webtransport >>> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > --0000000000009ada5e05ab465546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Virat said:=C2=A0

    "I got the impre= ssion that HTTP/3 calls like fetch and Http3Transport will be able to share= a connection from=C2=A0draft-vvv-webtransport-htt= p3-02#section-1=C2=A0where it says "Using the mechanism described here,= =C2=A0multiple Http3Transport instances can be multiplexed simultaneously= =C2=A0with regular HTTP traffic on the same HTTP/3 connection"= ;.

    [BA] The WebTransport API spec seems to imply s= ome (or maybe all) of this, but there isn't any implementation experien= ce AFAIK.

    "An example would be an app where f= ull-duplex communication is required only at a particular step of the user = flow (ex. taxi booking or food ordering application), like at the time of l= ive location sharing or chat support, but the rest of the functionality req= uires only client to server API calls. Some of these actions can be simulta= neously performed by the user like live location sharing=C2=A0+ browsing th= rough the app and thus making some fetch calls."=C2=A0

    <= /div>
    [BA] Question: In this use case, is there an interaction between = HTTP/3 traffic and WebTransport traffic?=C2=A0 For example, in the RIPT BOF= there were examples shown where an HTTP/3 Request elicited an HTTP/3 Respo= nse as well as HTTP/3 datagram traffic from server to client.=C2=A0 The ide= a was to enable SIP-like exchanges to occur within HTTP/3 so as to enable c= alling.=C2=A0

    This would enable the taxi booking o= r food ordering application to allow the user to talk to the taxi driver or= submit their food order in a voice call, using a single HTTP/3 Connection.=



    On Fri, Jul 24, 2020 at 4:30 AM virat t= ara <virattara@gmail.com> = wrote:
    Hi Bernard,
    =C2=A0
    Note that the Http3Transport=C2=A0 constructor doesn't = have an optional QuicTransport object as an argument, so that there's n= o way to "share" a QUIC=C2=A0transport between Http3 (as used by = say, fetch) and Http3Transport.

    I got t= he impression that HTTP/3 calls like fetch and Http3Transport will be able = to share a connection from=C2=A0draft-vvv-webtrans= port-http3-02#section-1=C2=A0where it says "Using the mechanism describ= ed here,=C2=A0multiple Http3Transport instances can be multiplexed simult= aneously=C2=A0with regular HTTP traffic on the same HTTP/3 connection".

    The ability to share a QUIC connection between HTTP3 (e.g. fetch) and= WebTransport (via WebTransport API) has come up from time to time. Do you = have a use case where this would be valuable?

    An example would be an app where full-duplex communication is requir= ed only at a particular step of the user flow (ex. taxi booking or food ord= ering application), like at the time of live location sharing or chat suppo= rt, but the rest of the functionality requires only client to server API ca= lls. Some of these actions can be simultaneously performed by the user like= live location sharing=C2=A0+ browsing through the app and thus making some= fetch calls.

    One can argue that the fetch calls b= eing stateless can be converted into=C2=A0events to make them compatible wi= th WebTransport. I think that's=C2=A0not a simple decision to make once= you have built up an application and later on decide to incorporate a smal= l feature that requires full duplex communication on the same server. One c= an always resort to HTTP Long Polling in such cases and I think this is one= of the main reasons long polling is still in use and not obsolete.=C2=A0RFC 8441 would have made it obsolete but it is yet to be rolled out on major brows= ers.

    On Fri, Jul 24, 2020 at 7:12 AM Bernard A= boba <berna= rd.aboba@gmail.com> wrote:
    Martin= said:=C2=A0

    "That's a good point.=C2=A0 My und= erstanding of the HTTP mappings is that you can make several "instance= s" of the WebTransport thing in the one connection."
    [BA] Here is the current Http3Transport=C2=A0constructor:=C2= =A0

    [Exposed=3D(Window,<=
span style=3D"color:rgb(0,119,170)">Worker)]
interface Http3Transport {
  constructor(DOMString url);
};

    It only takes a url as an argument (like = the WebSocket constructor).=C2=A0 So the implication is that invoking the c= onstructor creates a distinct QUIC connection.=C2=A0 But using that QUIC=C2= =A0connection, it is possible to create multiple bi-directional or uni-dire= ctional streams or send datagrams in either direction.=C2=A0 So "pooli= ng" or other sharing of an Http3Transport is already supported to a si= gnificant extent.=C2=A0

    Martin said:=C2=A0
    "Even if you only have one WebTransport thing, you can still use th= e same connection for HTTP and the thing."=C2=A0

    <= div>[BA]=C2=A0 Note that the Http3Transport=C2=A0 constructor doesn't h= ave an optional QuicTransport object as an argument, so that there's no= way to "share" a QUIC=C2=A0transport between Http3 (as used by s= ay, fetch) and Http3Transport.

    There is a reason w= hy this isn't supported, even though it was something that seemed quite= desirable. HTTP/3 is very specific on how it uses Stream IDs, so it would = be quite tricky to have both the WebTransport and another API like fetch sh= aring a QUIC connection.=C2=A0


    =

    On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson <mt@lowentropy.net> = wrote:
    On Fri, J= ul 24, 2020, at 04:33, virat tara wrote:
    > For an app that would use both regular HTTP calls and WebTransport, > from the server's perspective, won't using HttpTransport inste= ad of a
    > dedicated connection like in QuicTransport help it to reduce the numbe= r
    > of active connections/sockets per client? Thus allowing it to serve > more distinct clients per server. Particularly for apps that make
    > occasional HTTP calls and heavily rely on a full-duplex protocol for <= br> > the rest of their working.

    That's a good point.=C2=A0 My understanding of the HTTP mappings is tha= t you can make several "instances" of the WebTransport thing in t= he one connection.=C2=A0 Even if you only have one WebTransport thing, you = can still use the same connection for HTTP and the thing.=C2=A0 With a dedi= cated transport, it seems like you just have one.=C2=A0

    Of course that one is capable of a lot of concurrency, so you might be comf= ortable with not having multiple sessions, but I can imagine cases for shar= ing different logical contexts that can be split at a gateway.

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --0000000000009ada5e05ab465546-- From nobody Sat Jul 25 17:09:04 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9CD3A0B9C for ; Sat, 25 Jul 2020 17:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 tnzls2l2rwUm for ; Sat, 25 Jul 2020 17:09:00 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 E92923A0B99 for ; Sat, 25 Jul 2020 17:08:59 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id k71so7211696pje.0 for ; Sat, 25 Jul 2020 17:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=IUXgYtcq/Kdd8rBtaozEBe2DkFNZXl2QMn13AYVl4zM=; b=C1p3jMyNF0ULqL92ovpdegHOyx+97ir0oh4uOEjqqanNl+glodNW5IocDy7+eb1whN xIvyhz293tFWQ9AzwWyYz5NLNkhO3PN3tLLZ71x8BKUKE0/oLEgRhMTgYJjz6h6xLAmf nknRA2vsh7bfO/kEfWbCMsdNObBeaeddHhUW9a0LWUsDBA7MW+tEmr6MvVga9CRDTBI0 A5eDhD2AX8usEeHxUX4GJ3lJMOuv2G/ED6VKwPR90uH24IQzjT4M3NJxcLTZ5cykwDmB IZKHz0zMOlVtF7AAwwNNjyiyboTmeWEkl0SWqgXHs97m/5P7FRmtv3GQIU/34yMdQQNn s27Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=IUXgYtcq/Kdd8rBtaozEBe2DkFNZXl2QMn13AYVl4zM=; b=HjagfKTHDvNnbIrkbqKfytlRfjAreEXj8Q9bjGft7hCtosOzXjBuou8OhQBzgHGbsD GIkUFe2MCOBY/jWjkbS1J+Zbnxdun9b+XYdJNxGjUEuPAJVSjXWpIzS05dcg5sAMTPvt Qcl4FLcvm44jKo6ejmgPBmIkpCRomoHr+r0GzRWZPo+/zRYD1+0weHHXF21H8ewoq64O lr63pFbIiW26UvWqWeh6SNliQdOuvRXZeY2Mz3Bt0ZUrH4Y0d9qh8z0Ppfcu4oz7UUBa bLZO/2R8NF+HaIjnQAfAtujAuQ9n4xI9R9REtUNpXS/Tdb07LcAZrEt82iZHDktP7q/u UmMw== X-Gm-Message-State: AOAM530dKmFKZz67hXPLpdF0VEhXyoK9UfZJD9cYNvMoqSllQmo9qqTV i0vc19xkamNagf0ZYyH9gpHo03xkn4A= X-Google-Smtp-Source: ABdhPJwOq7tGMNKjkPlvkrURA3u14OysWokhB1W/9nbdZBwdCLjSShexXb8uybZO+hFiyNoUe4Qk6w== X-Received: by 2002:a17:90a:178e:: with SMTP id q14mr11506093pja.80.1595722138662; Sat, 25 Jul 2020 17:08:58 -0700 (PDT) Received: from [192.168.1.103] (c-71-227-236-207.hsd1.wa.comcast.net. [71.227.236.207]) by smtp.gmail.com with ESMTPSA id gv16sm9638889pjb.5.2020.07.25.17.08.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Jul 2020 17:08:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-920E4BEE-F461-49F2-82B4-B62035AE011C Content-Transfer-Encoding: 7bit From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Sat, 25 Jul 2020 17:08:57 -0700 Message-Id: <3084C7A6-B2C3-4C44-A567-3178FEC45C6B@gmail.com> References: In-Reply-To: To: WebTransport X-Mailer: iPhone Mail (17G68) Archived-At: Subject: Re: [Webtransport] Does WebTransport need a reliable, in-order message abstraction? X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 00:09:02 -0000 --Apple-Mail-920E4BEE-F461-49F2-82B4-B62035AE011C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alan said:=20 > Is replacing WebSockets with WebTransport one of our goals? If so, I thin= k we need to address the gap by adding this abstraction. If not, we should e= xplicitly mention that this abstraction doesn=E2=80=99t exist, and instruct d= evelopers to use WebSocket instead. [BA] Thanks for bringing this up. When we first started on what would become the RTCQuicTransport API, the goa= l was to support all the transport modes of the RTCDataChannel API, which wa= s modelled after WebSockets.=20 However, we realized that this required design of a framing protocol on top o= f QUIC reliable streams. After verifying that a simple framing protocol was i= mplementable as a JS library on top of the RTCQuicTransport prototype, provi= ding many of the services of RTCDataChannel, the =E2=80=9Cproof of concept=E2= =80=9D was considered done and since then not much has happened. This is a good example of how things can fall between the cracks of protocol= design and API design. =E2=80=9CAssume we have a framing protocol designed i= n IETF....=E2=80=9D= --Apple-Mail-920E4BEE-F461-49F2-82B4-B62035AE011C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Alan said: 

    = Is replacing WebSockets with WebTransport one of our goals?  If so, I t= hink we need to address the gap by adding this abstraction.  If not, we= should explicitly mention that this abstraction doesn=E2=80=99t exist, and i= nstruct developers to use WebSocket instead.

    [BA] Thanks for bringing this up.

    <= /div>
    When we first started on what would become the RTCQuic= Transport API, the goal was to support all the transport modes of the RTCDat= aChannel API, which was modelled after WebSockets. 

    However, we realized that this required design= of a framing protocol on top of QUIC reliable streams. After verifying that= a simple framing protocol was implementable as a JS library on top of the R= TCQuicTransport prototype, providing many of the services of RTCDataChannel,= the =E2=80=9Cproof of concept=E2=80=9D was considered done and since then n= ot much has happened.

    This i= s a good example of how things can fall between the cracks of protocol desig= n and API design. =E2=80=9CAssume we have a framing protocol designed in IET= F....=E2=80=9D
    = --Apple-Mail-920E4BEE-F461-49F2-82B4-B62035AE011C-- From nobody Sat Jul 25 17:23:45 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D963A0BA9 for ; Sat, 25 Jul 2020 17:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 YRvM2Jx6Yeon for ; Sat, 25 Jul 2020 17:23:43 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 B578F3A0BA5 for ; Sat, 25 Jul 2020 17:23:42 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id c80so10973055wme.0 for ; Sat, 25 Jul 2020 17:23:42 -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=Zvdobo+CKM4LIBiO3xFCyp9r1PNmIW6J5BI7YQoGQIc=; b=NdZ8urEszzGLD3uBJrUeOKRJL/CeJ/dHx0gUunAirmd3Qh4s3Fb9ldsP3UXxKhhN64 IwAvAoLHlZHgISG+jU5l5sRVhzsTojt87hB5EZxlzwhuJxPTaN697A6e/jovYiKWp6fL AcS+495Lm/N4oX0q+jw0RvomefOY+8CbJ1MJJahDQxC1FUFK5rdjr2POWXyER1Itb+o5 MGjY+LQOELLmzIQI2SY9Pu/zzROAKDeD5UVrCMy9rqnKujaHw4femsXo8rZn5u9ng58y 53qg8WLWQ0eNaD5xIUTyKNrLsId/sZSx3en+0ACI9aLD/kZK0jo2+ez7igTKdiB90S8S WH5Q== 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=Zvdobo+CKM4LIBiO3xFCyp9r1PNmIW6J5BI7YQoGQIc=; b=XNxt9npNpjMTaquT/ewwIAgmm7yhTOCi0boZ3CdUww8d6KD9Dk7B6Ine6J7faCrt/l VXgMHW6nkb8/cdsClqXUUDW+i3HruyDBq7vStUYQJ1C4S7vVkF+rc3JgNLlI8Yviq8kO 8z/cQ872aVWHrmy/nS0fQTfYxLneM2sJdVAFuuyFZEWnsO4o+G6VhCTDqxPQCVnsXHCH IO42IAJmAjPTSlp/O+mRF0hLJPWYOtKGmXKB1Og8WviF69qmlUMbkLjV63SkliAoVOcA 5CwpuWVTjtcVi9NZdLuyiVjnW2eXZ+X51nXEK6EA4yPODUVH0vS44ARtrdLIqeY9KWtT yA3g== X-Gm-Message-State: AOAM531Nc6C/WiaxhMOKcK2Q6vj7lf3zU+Dmaw4N2/auvsXaPgFPu4Sk ggjMmTNfXsKYyXgzpu/6aps3ySOc1/6xaly1N9o= X-Google-Smtp-Source: ABdhPJx8a2Dw+CZRm2h/5BZZcVBy+dPfuAbgJw025LFRz81FUrS609tl99VjLfFb7EjEFM7YGIp+wStdeff6MvqVGQ0= X-Received: by 2002:a1c:19c4:: with SMTP id 187mr15110459wmz.100.1595723021157; Sat, 25 Jul 2020 17:23:41 -0700 (PDT) MIME-Version: 1.0 References: <3084C7A6-B2C3-4C44-A567-3178FEC45C6B@gmail.com> In-Reply-To: <3084C7A6-B2C3-4C44-A567-3178FEC45C6B@gmail.com> From: Lucas Pardue Date: Sun, 26 Jul 2020 01:23:30 +0100 Message-ID: To: Bernard Aboba Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000d60bcc05ab4d371b" Archived-At: Subject: Re: [Webtransport] Does WebTransport need a reliable, in-order message abstraction? X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 00:23:45 -0000 --000000000000d60bcc05ab4d371b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this question identifies a pretty interesting dynamic between WebSocket and WebTransport. There is some overlap with the thread about what protocols/fallbacks we want to implement. Given the prevalence of WebSocket today, one might want to incentivise people to switch to the same capability over WebTransport, but what would that look like? What's the upgrade path here for devs that use a wss scheme today? Perhaps some mapping of WebSockets, as they are used today, into WebTransport would aid uptake and avoid relegating WebSockets to always be stuck in their own isolated TCP connection (because the rollout of WebSockets over H2 is limited) Cheers Lucas On Sun, Jul 26, 2020 at 1:09 AM Bernard Aboba wrote: > Alan said: > > Is replacing WebSockets with WebTransport one of our goals? If so, I > think we need to address the gap by adding this abstraction. If not, we > should explicitly mention that this abstraction doesn=E2=80=99t exist, an= d instruct > developers to use WebSocket instead. > > > [BA] Thanks for bringing this up. > > When we first started on what would become the RTCQuicTransport API, the > goal was to support all the transport modes of the RTCDataChannel API, > which was modelled after WebSockets. > > However, we realized that this required design of a framing protocol on > top of QUIC reliable streams. After verifying that a simple framing > protocol was implementable as a JS library on top of the RTCQuicTransport > prototype, providing many of the services of RTCDataChannel, the =E2=80= =9Cproof of > concept=E2=80=9D was considered done and since then not much has happened= . > > This is a good example of how things can fall between the cracks of > protocol design and API design. =E2=80=9CAssume we have a framing protoco= l designed > in IETF....=E2=80=9D > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000d60bcc05ab4d371b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I think this question identifies a pretty interesting= dynamic between WebSocket and WebTransport. There is some overlap with the= thread about what protocols/fallbacks we want to implement.

    Given = the prevalence of WebSocket today, one might want to incentivise people to = switch to the same capability over WebTransport, but what would that look l= ike? What's the upgrade path here for devs that use a wss scheme today?= Perhaps some mapping of WebSockets, as they are used today, into WebTransp= ort would aid uptake and avoid relegating WebSockets to always be stuck in = their own isolated TCP connection (because the rollout of WebSockets over H= 2 is limited)

    Cheers
    Lucas

    On S= un, Jul 26, 2020 at 1:09 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
    Ala= n said:=C2=A0

    Is replacing WebSockets with WebTransport one of our = goals?=C2=A0 If so, I think we need to address the gap by adding this abstr= action.=C2=A0 If not, we should explicitly mention that this abstraction do= esn=E2=80=99t exist, and instruct developers to use WebSocket instead.

    [BA] Thanks for bringing this up.=

    When we first started on = what would become the RTCQuicTransport API, the goal was to support all the= transport modes of the RTCDataChannel API, which was modelled after WebSoc= kets.=C2=A0

    However, we re= alized that this required design of a framing protocol on top of QUIC relia= ble streams. After verifying that a simple framing protocol was implementab= le as a JS library on top of the RTCQuicTransport prototype, providing many= of the services of RTCDataChannel, the =E2=80=9Cproof of concept=E2=80=9D = was considered done and since then not much has happened.

    This is a good example of how things can fa= ll between the cracks of protocol design and API design. =E2=80=9CAssume we= have a framing protocol designed in IETF....=E2=80=9D
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --000000000000d60bcc05ab4d371b-- From nobody Mon Jul 27 00:58:11 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D597E3A1790 for ; Mon, 27 Jul 2020 00:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MUvrGitTeUa8 for ; Mon, 27 Jul 2020 00:58:06 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 BB70C3A178C for ; Mon, 27 Jul 2020 00:58:05 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id g6so3545301ljn.11 for ; Mon, 27 Jul 2020 00:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cCBsoUI3dnSAqfBMfGg9CNCNIc380+fPzT0kQ2pLUtE=; b=mmpUol2MXXeoFz/MB15iS8Kld43fdbnU/KEkfnyaKgNnLriM4in3BzAjoySZYo7CJg /SuisYwXPvRsjsEkQiptxbKZ2VdGOK0Uftjmj0k5euazw6yAFKHEPjd9jqOACukw1JVu EY9nQVY6QIzWjiP6hgfLv+LBUe0/BstLsSmGDbDkqc+IWHJ1n/4l/oYId+ZpcQNybybP XPZoGIdHwO8qg+4nneW/mbFPOX6Lxy1kBfUvW0uNNJcuL0OwqbCAKGzkI0udpjjItOI7 5/w9LbVs/tNkf7tSjaiY10cmnHXKM93DF40T5Nns/bcZlTHGyrQMcj2v4gzJNn1Fox7V VPpg== 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=cCBsoUI3dnSAqfBMfGg9CNCNIc380+fPzT0kQ2pLUtE=; b=N8HBIqWqWtZ3gBwupvPmdBhcxWBi2m45HZUKGBeST0as0ga+1+KAeXDX1/Qw04cVYA /fNl5zszJ9pZkvbWXIT3FXDpt3YRG1MNMaCw9v/Hnp+nTV13I3rPxd9G0wZNjZLFTeCE t05Ulx9h4vVVMhXZx2eOZaVXCFEsErOixurKzUKRmADPczUqXy7fiRuRQ9e6U13fZQrM d2BGu2VjoTjqt5lIsV6s1qgO5N13lEnE4nf7VrH82iFjRnC+RVb1h/SRBmeqisdJQKVi IdHkkTwulLnFDOZgZFyN0BDJI83pWm2rgxxRYnchADjeCUt+H2zUlkcB077vSIbOy4Vw 7ecg== X-Gm-Message-State: AOAM533O1VVkRGA6il3BXqkhECd0BFGkzYzpca/VdoOgt38qbSB6UFTC JQ8CVLRH6VxpGFUw8FBIYYqO9yShBaQpm/lNgVpZTSxBGTvnWA== X-Google-Smtp-Source: ABdhPJyocgYQDORXCiX9iALYyqaMVWIqQANyeGm7iFw4pJe82mpO2/+8HfgTHy93L7V4wqe5pmyn4Lvkiy0Z+FrKAqs= X-Received: by 2002:a2e:9e89:: with SMTP id f9mr8721684ljk.212.1595836683592; Mon, 27 Jul 2020 00:58:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yutaka Hirano Date: Mon, 27 Jul 2020 16:57:50 +0900 Message-ID: To: Victor Vasiliev Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000a59c8005ab67ae45" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 07:58:10 -0000 --000000000000a59c8005ab67ae45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > If we decide that QuicTransport is a way to go, we=E2=80=99d have to add = more features into its handshake, since I suspect most people won=E2=80=99t be h= appy with what=E2=80=99s in there right now (HTTP headers like Location or Forwa= rded would be a good example of what people would end up needing in practice, together with an ability to tag along arbitrary key-value metadata for debugging purposes). If we decide that HttpTransport is a way to go, we would have to ensure that the result is easy for Web developers to use, and that we understand the differences between it and regular HTTP. Is this for web developers or non-web users? WebSocket uses the Upgrade mechanism and uses HTTP headers, but doesn't expose most of the information. For example, we don't expose the HTTP status code to web developers. The only information it exposes to web developers is - whether the connection is established - protocol (sec-websocket-protocol) - extensions (sec-websocket-extensions) . I'm a bit concerned about confusion we would see with having yet another HTTP-like protocol. To what extent it is similar to HTTP is difficult, and people would have diverse expectations I think, given the experience in WebSocket. On Thu, Jul 23, 2020 at 6:23 AM Victor Vasiliev wrote: > Hello everyone, > > We recently adopted the overview draft > that > describes the general requirements for and the model of WebTransport. > However, we haven't yet adopted any specific wire protocol proposals. > There are currently three of those presented to the working group: > > - QuicTransport > > - Http2Transport > > - Http3Transport > > - [hypothetical WebTransport over WebSocket] > > Back when the original idea of WebTransport was forming, the hope was to > implement and ship all four of those, since they all fit different use > cases better. After talking more to the people at IETF, it sounds like > four transports is a bit too much, and we should settle on two (one over > QUIC, and one over TCP). The natural picks would be either Http3Transpor= t > with Http2Transport as fallback (HttpTransport for short), or QuicTranspo= rt > with=E2=80=A6 *something* as a fallback. Let=E2=80=99s look at the diffe= rences between > those two options. > > *Differences* > > The most substantial wire format difference between those two proposals i= s > the handshake. QuicTransport originally did not have any handshake; we h= ad > to add a bespoke handshake later in order to implement the Origin header, > and we also added a Path header later on. We currently don=E2=80=99t hav= e any form > of response headers, so if the server is unhappy with the origin or path > received, it has to close the connection with CONNECTION_CLOSE.. In > HttpTransport, we have regular HTTP header fields for both request and > response, meaning that the server can do things like return a 4xx/5xx for > an error. > > During the connection itself, the difference is minimal: QuicTransport > uses streams and datagrams as-is, while Http3Transport prefixes everythin= g > with an ID, since it is multiplexed with other HTTP traffic. There might > be a question of whether prefixing can impose undesirable framing overhea= d; > I think if that ever becomes a serious problem, we can come up with some > extension to work this around. > > If we decide that QuicTransport is a way to go, we=E2=80=99d have to add = more > features into its handshake, since I suspect most people won=E2=80=99t be= happy > with what=E2=80=99s in there right now (HTTP headers like Location or For= warded > would be a good example of what people would end up needing in practice, > together with an ability to tag along arbitrary key-value metadata for > debugging purposes). If we decide that HttpTransport is a way to go, we > would have to ensure that the result is easy for Web developers to use, a= nd > that we understand the differences between it and regular HTTP. > > From the server complexity standpoint, I am not particularly worried abou= t > either. We=E2=80=99ve implemented QuicTransport in Chrome, and I wrote t= wo servers > for it, in C++ and in Python; the Python one took about 100 lines of code= . > Http2Transport has been implemented, in somewhat different forms, by both > Apple and Facebook, so we have practical experience with it too.. I was > previously concerned that having to implement HPACK/QPACK would be a burd= en > to the Web developers since those are more complex than what you=E2=80=99= d > typically find in a WebSocket implementation, but now that we have a > draft to turn compression off > , I=E2=80=99m less= worried > about this. > > There is a question of how much of the HTTP ecosystem we would be actuall= y > getting by adopting HTTP. It is true that basing WebTransport on HTTP do= es > not mean HTTP middleware would automatically implement it. That said, we > do get a lot of useful features from HTTP, notably message routing and a > well-understood metadata format. Everyone knows what a code 200 or 404 i= s, > and a lot of people have built their internal debugging/tracing tools bas= ed > on adding HTTP headers to things, and being able to easily port those to > WebTransport would be an asset. I=E2=80=99ve seen some arguments that co= ntent > negotiation and caching might be applicable to certain classes of > WebTransport resources too (e.g. a live stream can be cached in the sense > that requesting a live stream is joining it), though those kinds of cases > would have to be content-specific and they do not generalize as nicely as > caching for regular HTTP resources. An interesting point to note is that > WebTransport is always included programmatically (as opposed to being > navigated to or sourced via URL from HTML), thus alleviating the need for= a > lot of otherwise useful HTTP headers. > > *Questions* > > While on the surface the question here is =E2=80=9Cwhich drafts should we= adopt?=E2=80=9D, > I would like to break this question down into two layers: > > 1. Do we want to use the wire format in which we try to build > minimally on top of QUIC (QuicTransport), or do we base it on HTTP? > 2. To what extent WebTransport connections act like HTTP connections? > Do they have https URLs or a dedicated schema? Which HTTP headers do = and > don=E2=80=99t work? > > > Regarding the first issue, I am increasingly leaning towards keeping only > the HTTP-based option. QuicTransport=E2=80=99s most appealing feature is = its > simplicity; however, ever since we=E2=80=99ve had to add a header to comm= unicate > the Web origin, there has been increasingly more and more reasons to add > new features to it, so even if we go that way, we=E2=80=99re probably goi= ng to end > up with something that=E2=80=99s a lot like HTTP. Also, we know exactly = how to do > TCP fallback in this case, so this removes a lot of design problems from > consideration. Fixing complexity and other problems with HTTP is probabl= y > more viable. > > Regarding the second issue, I am not sure how much of it is in scope for > this working group. While we do need to define a URL schema, and the > choice of schema will give us a lot of answer (by making WebTransport sam= e > or different origin as HTTP), a lot of those questions have been > traditionally answered somewhere in Fetch spec, or simply not addressed i= n > the standards at all. I am not quite sure what to do with those. > > What do people think? > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000a59c8005ab67ae45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    > If we decide that QuicTransport is a way to = go, we=E2=80=99d have to add more features into its handshake, since I susp= ect most people won=E2=80=99t be happy with what=E2=80=99s in there right n= ow (HTTP headers like Location or Forwarded would be a good example of what= people would end up needing in practice, together with an ability to tag a= long arbitrary key-value metadata for debugging purposes).=C2=A0 If we deci= de that HttpTransport is a way to go, we would have to ensure that the resu= lt is easy for Web developers to use, and that we understand the difference= s between it and regular HTTP.=C2=A0=C2=A0

    Is this for web developers or = non-web users?
    WebSocket uses the Upgrade= mechanism and uses HTTP headers, but doesn't expose most of the inform= ation.=20 For example, we don't expose the HTTP status code to web developers. Th= e only information it exposes to web developers is
    =C2=A0- whether the connection is established
    =C2=A0- protocol (sec-websocket-protocol)
    =C2=A0- extensions (sec-websocket-extensions)
    .

    I'm a bit concerned about confusion we would see = with having yet another HTTP-like protocol. To what extent it is similar to= HTTP is difficult, and people would have diverse expectations I think, giv= en the experience in WebSocket.

    On Thu, Jul 23, 2020 at 6:23 AM = Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
    Hello everyone,

    We rec= ently adopted the overview draft that describes the gene= ral requirements for and the model of WebTransport.=C2=A0 However, we haven= 't yet adopted any specific wire protocol proposals.=C2=A0 There are cu= rrently three of those presented to the working group:
    Back when the original idea of WebTransport was form= ing, the hope was to implement and ship all four of those, since they all f= it different use cases better.=C2=A0 After talking more to the people at IE= TF, it sounds like four transports is a bit too much, and we should settle = on two (one over QUIC, and one over TCP).=C2=A0 The natural picks would be = either Http3Transport with Http2Transport as fallback (HttpTransport for sh= ort), or QuicTransport with=E2=80=A6 something as a fallback.=C2=A0 = Let=E2=80=99s look at the differences between those two options.

    = Differences

    The most substantial wire format difference between = those two proposals is the handshake.=C2=A0 QuicTransport originally did no= t have any handshake; we had to add a bespoke handshake later in order to i= mplement the Origin header, and we also added a Path header later on.=C2=A0= We currently don=E2=80=99t have any form of response headers, so if the se= rver is unhappy with the origin or path received, it has to close the conne= ction with CONNECTION_CLOSE..=C2=A0 In HttpTransport, we have regular HTTP = header fields for both request and response, meaning that the server can do= things like return a 4xx/5xx for an error.

    During the connection it= self, the difference is minimal: QuicTransport uses streams and datagrams a= s-is, while Http3Transport prefixes everything with an ID, since it is mult= iplexed with other HTTP traffic.=C2=A0 There might be a question of whether= prefixing can impose undesirable framing overhead; I think if that ever be= comes a serious problem, we can come up with some extension to work this ar= ound.

    If we decide that QuicTransport is a way to go, we=E2=80=99d h= ave to add more features into its handshake, since I suspect most people wo= n=E2=80=99t be happy with what=E2=80=99s in there right now (HTTP headers l= ike Location or Forwarded would be a good example of what people would end = up needing in practice, together with an ability to tag along arbitrary key= -value metadata for debugging purposes).=C2=A0 If we decide that HttpTransp= ort is a way to go, we would have to ensure that the result is easy for Web= developers to use, and that we understand the differences between it and r= egular HTTP.

    From the server complexity standpoint, I am not particu= larly worried about either.=C2=A0 We=E2=80=99ve implemented QuicTransport i= n Chrome, and I wrote two servers for it, in C++ and in Python; the Python = one took about 100 lines of code.=C2=A0 Http2Transport has been implemented= , in somewhat different forms, by both Apple and Facebook, so we have pract= ical experience with it too..=C2=A0 I was previously concerned that having = to implement HPACK/QPACK would be a burden to the Web developers since thos= e are more complex than what you=E2=80=99d typically find in a WebSocket im= plementation, but now that we have a draft to turn compression off= , I=E2=80=99m less worried about this.

    There is a question of ho= w much of the HTTP ecosystem we would be actually getting by adopting HTTP.= =C2=A0 It is true that basing WebTransport on HTTP does not mean HTTP middl= eware would automatically implement it.=C2=A0 That said, we do get a lot of= useful features from HTTP, notably message routing and a well-understood m= etadata format.=C2=A0 Everyone knows what a code 200 or 404 is, and a lot o= f people have built their internal debugging/tracing tools based on adding = HTTP headers to things, and being able to easily port those to WebTransport= would be an asset.=C2=A0 I=E2=80=99ve seen some arguments that content neg= otiation and caching might be applicable to certain classes of WebTransport= resources too (e.g. a live stream can be cached in the sense that requesti= ng a live stream is joining it), though those kinds of cases would have to = be content-specific and they do not generalize as nicely as caching for reg= ular HTTP resources.=C2=A0 An interesting point to note is that WebTranspor= t is always included programmatically (as opposed to being navigated to or = sourced via URL from HTML), thus alleviating the need for a lot of otherwis= e useful HTTP headers.

    Questions

    While on the surface = the question here is =E2=80=9Cwhich drafts should we adopt?=E2=80=9D, I wou= ld like to break this question down into two layers:
    1. Do we want = to use the wire format in which we try to build minimally on top of QUIC (Q= uicTransport), or do we base it on HTTP?
    2. To what extent WebTranspor= t connections act like HTTP connections?=C2=A0 Do they have https URLs or a= dedicated schema?=C2=A0 Which HTTP headers do and don=E2=80=99t work?
      3. =

    Regarding the first issue, I am increasingly leaning towards keepi= ng only the HTTP-based option. QuicTransport=E2=80=99s most appealing featu= re is its simplicity; however, ever since we=E2=80=99ve had to add a header= to communicate the Web origin, there has been increasingly more and more r= easons to add new features to it, so even if we go that way, we=E2=80=99re = probably going to end up with something that=E2=80=99s a lot like HTTP.=C2= =A0 Also, we know exactly how to do TCP fallback in this case, so this remo= ves a lot of design problems from consideration.=C2=A0 Fixing complexity an= d other problems with HTTP is probably more viable.

    Regarding the se= cond issue, I am not sure how much of it is in scope for this working group= .=C2=A0 While we do need to define a URL schema, and the choice of schema w= ill give us a lot of answer (by making WebTransport same or different origi= n as HTTP), a lot of those questions have been traditionally answered somew= here in Fetch spec, or simply not addressed in the standards at all.=C2=A0 = I am not quite sure what to do with those.

    What do people think?
    =
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --000000000000a59c8005ab67ae45-- From nobody Mon Jul 27 01:16:32 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF53A17A4 for ; Mon, 27 Jul 2020 01:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 31XMvWTSS7cE for ; Mon, 27 Jul 2020 01:16:29 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 A53343A17A0 for ; Mon, 27 Jul 2020 01:16:28 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id qc22so1331408ejb.4 for ; Mon, 27 Jul 2020 01:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=0FYJmRlaj0IzKW/krV1xdQsZKlzdrPRi5qmnKP9eZ0k=; b=pmE+v9LQQaI+K/ACYIlxm9Y7gZLV6qZ1pqiq7nkTznWIjem/jqOlAqnL6utomYXsq1 td5b3FgzNxnevPfzt8VJZ0yf/VbnkAx6nvmL39cRYX0OLPbBkkcHGaSUo4IcWEjfAYsw g/UanIPamK/svRdhu0/mnMR7BtUnFBWHjUxvdyE+UTMXDmOer/2C87y1XHtq9sOwbkB6 J0H5HIribCuYjaV8mUPgKi221+cyK2VVwNmlutiKJayCaB9a53ZNMx9FwM6NrjmsMAJS 2jn9/31WgSrue4/big7c3E9pJMhxXdaXvvn5EIndvCAjtrVkHBQRrygk7BLDkJ0gDYmL vmww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0FYJmRlaj0IzKW/krV1xdQsZKlzdrPRi5qmnKP9eZ0k=; b=aDCumwg8mdJ8AdOvVUKCHc+kVEVholM7ECa5lDj+CgZEKO3YSAsw/kl3DzygWh+C4C xI1hxHRTDWIckGFy/Fy6N11MVYyHMco4wxrlh7CtlK2AH9atSgHzW7/E4u1O0B7L+tDH U/vnp/zg2ClSFCWbASno86x85dHUDRKgGN+zVs1Sn1Ln4AJaeBhyknGN/OxJFIkVAJJ4 EvUmepfc24+VBZyfVyJKTmZ0g0f6KelT69Tf8qfOzZyia4+o3lbK+IdNFSNshO8cYfKW SslhRnti857YRAIkAMA0X1dKiO9yy8FRAAs3CZIBoW6kOZHZ3Jhpon8bIWQ9dAY8xDr9 NpDQ== X-Gm-Message-State: AOAM532jGyJdPQ/OAJbZ49/g4sY+RK9j+y0XZdyW5Cu7S87w7bSd7hZK txUA+UKB4LBwyYV2u3LAQ969yVd0 X-Google-Smtp-Source: ABdhPJzS0lr7lBVm0nbedH1yfEyvQKBESJ1W7nZcKgfVtvW5Fh1BlPHTi9dLvosVE1seYUrqiLzZbA== X-Received: by 2002:a17:906:43c9:: with SMTP id j9mr4090812ejn.542.1595837786752; Mon, 27 Jul 2020 01:16:26 -0700 (PDT) Received: from ?IPv6:2001:1620:6cf:0:a18a:7d9:9864:f71e? ([2001:1620:6cf:0:a18a:7d9:9864:f71e]) by smtp.gmail.com with ESMTPSA id z25sm6483508ejd.38.2020.07.27.01.16.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2020 01:16:26 -0700 (PDT) To: webtransport@ietf.org References: <3084C7A6-B2C3-4C44-A567-3178FEC45C6B@gmail.com> From: Lennart Grahl Message-ID: <2b7f05a8-2b6c-231f-7f95-b18462261bdb@gmail.com> Date: Mon, 27 Jul 2020 10:16:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3084C7A6-B2C3-4C44-A567-3178FEC45C6B@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Webtransport] Does WebTransport need a reliable, in-order message abstraction? X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 08:16:31 -0000 On 26/07/2020 02:08, Bernard Aboba wrote: > Alan said: > >> Is replacing WebSockets with WebTransport one of our goals? If so, I think we need to address the gap by adding this abstraction. If not, we should explicitly mention that this abstraction doesn’t exist, and instruct developers to use WebSocket instead. > > [BA] Thanks for bringing this up. > > When we first started on what would become the RTCQuicTransport API, the goal was to support all the transport modes of the RTCDataChannel API, which was modelled after WebSockets. > > However, we realized that this required design of a framing protocol on top of QUIC reliable streams. After verifying that a simple framing protocol was implementable as a JS library on top of the RTCQuicTransport prototype, providing many of the services of RTCDataChannel, the “proof of concept” was considered done and since then not much has happened. > > This is a good example of how things can fall between the cracks of protocol design and API design. “Assume we have a framing protocol designed in IETF....” Perhaps a clearly defined framing protocol for WebTransport on top of those protocols that need it is not a bad idea if it's simple and easily negotiable. But beyond that, I urge to always think about the entry-barrier for non-web implementations before adding more protocols. Because that was one of the top arguments when it came to why supporting data channels and SCTP in non-web implementations is a problem. But back to the "message" feature: I did make a proposal on that to make the API future-proof for message streams (i.e. stream of byte stream): https://github.com/WICG/web-transport/issues/49 If we do have a framing protocol, then it can be easily combined with the API proposal. And I want to emphasize again on the naming in the API. So far, these are all byte steams we're talking about in the WebTransport API but when adding "message" streams, this isn't clear any more. To quote myself in above linked issue: > [...] I think it makes sense to incorporate the type of stream into the interface in general to avoid confusion in a dynamically typed language (what kind of stream is this? a stream of bananas?) [...] From nobody Mon Jul 27 01:52:20 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8423A17D1 for ; Mon, 27 Jul 2020 01:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 u7mjUdzxUkuV for ; Mon, 27 Jul 2020 01:52:16 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 F18CC3A17CC for ; Mon, 27 Jul 2020 01:52:15 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id q16so6153948ybk.6 for ; Mon, 27 Jul 2020 01:52:15 -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=EisO2aBQFbsfxkr/Ji6FTmUBG5xYOaOihgGs42V2EfY=; b=gQCllsz5GgnF2hnCJP+xIJVtupObFfBwZZ2SayWc0wCvvj3DM39e3EzlrvNfwSzYS5 0EqykPPdKazsANTPvOxuFEBtrANQncjwh52hBfPAU+tHbk2ipSyBGK+2PBufdWtZeCqN HHLaK+9C49jzLB2qA2oo7XPIrgwSnW7lIqAwmiIQpnrXNIRaijqoQYZcidKDPE6GdGl8 /RFOgrmYbqBonC1O2KGjkgBRKBQEL3RkL1matkjXaLbtLNAF1vTztdddc8gG+0c9k9BP gQ1yjzRMs0q6m7xLbH37ec9sisBfyUGJGBcblFBA7rsiGDwSo/NRO9eD1b3lkw2vBmWM Ef6Q== 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=EisO2aBQFbsfxkr/Ji6FTmUBG5xYOaOihgGs42V2EfY=; b=Iu6kNN5ekM8NkhIRL3MCtKR4lhAsmXLooZrifWis1zLUKXgNrO5az3nCkocnPHGvZo U4NcEwUTnDXnSzPyLuMQ7tSgOYqUZ8+5FH0AQ+M5V9PWUetQezo+JMSlqvIFoDSzec+X pqaE4/3NQjlnPOZFeJ9dPlqnpPRZnhdT8bLITvnUDzcILQBfaH7R/474d7exIT530YgO ZnKGp0+UjDjORLnpKooJbfMc+oU975FQQJMvo55z2xQZj4n/+S5EArjFRxeUVaKDVZu4 Zu5vinOrdiUxQKdoG67MvnPa4X6F28MbmUWsjUH/dUd4qUWQ3zZThsMVswcBYRpmRlDh sXIg== X-Gm-Message-State: AOAM533trJZLSNRDOmRTiEJqYuc76HY4eYm1wagYehoR4AGHCnbrcwyH VATgVzpE7howNV0lN8Mbz+nJ01gVDGEOM7PDM6s= X-Google-Smtp-Source: ABdhPJyO0MMFd5El7mH+cJ5qFnBZh3dNqxWqmpSKRm7/NDZAykFSqGJtN7NF3WisL4k2gL6qx1PTVxjcadA4hOVkcSA= X-Received: by 2002:a05:6902:50a:: with SMTP id x10mr2373665ybs.181.1595839934780; Mon, 27 Jul 2020 01:52:14 -0700 (PDT) MIME-Version: 1.0 References: <55d2f1a0-1d88-4aeb-bfbb-e9d7ffc547f6@www.fastmail.com> In-Reply-To: From: virat tara Date: Mon, 27 Jul 2020 14:22:03 +0530 Message-ID: To: Bernard Aboba Cc: WebTransport Content-Type: multipart/alternative; boundary="0000000000006e5a9105ab6870e7" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 08:52:19 -0000 --0000000000006e5a9105ab6870e7 Content-Type: text/plain; charset="UTF-8" > > Bernard's question: In this use case, is there an interaction between > HTTP/3 traffic and WebTransport traffic? For example, in the RIPT BOF > there were examples shown where an HTTP/3 Request elicited an HTTP/3 > Response as well as HTTP/3 datagram traffic from server to client. The > idea was to enable SIP-like exchanges to occur within HTTP/3 so as to > enable calling. No, there is no interaction between HTTP/3 traffic and WebTransport traffic in my use case. This would enable the taxi booking or food ordering application to allow > the user to talk to the taxi driver or submit their food order in a voice > call, using a single HTTP/3 Connection. > Yes, this can be another use case where sharing of connection between HTTP/3 and Http3Transport (via RIPT) will be helpful. On Sat, Jul 25, 2020 at 9:40 PM Bernard Aboba wrote: > Virat said: > > "I got the impression that HTTP/3 calls like fetch and Http3Transport will > be able to share a connection from > draft-vvv-webtransport-http3-02#section-1 > where > it says "Using the mechanism described here, multiple Http3Transport > instances can be multiplexed simultaneously with regular HTTP traffic on > the same HTTP/3 connection". > > [BA] The WebTransport API spec seems to imply some (or maybe all) of this, > but there isn't any implementation experience AFAIK. > > "An example would be an app where full-duplex communication is required > only at a particular step of the user flow (ex. taxi booking or food > ordering application), like at the time of live location sharing or chat > support, but the rest of the functionality requires only client to server > API calls. Some of these actions can be simultaneously performed by the > user like live location sharing + browsing through the app and thus making > some fetch calls." > > [BA] Question: In this use case, is there an interaction between HTTP/3 > traffic and WebTransport traffic? For example, in the RIPT BOF there were > examples shown where an HTTP/3 Request elicited an HTTP/3 Response as well > as HTTP/3 datagram traffic from server to client. The idea was to enable > SIP-like exchanges to occur within HTTP/3 so as to enable calling. > > This would enable the taxi booking or food ordering application to allow > the user to talk to the taxi driver or submit their food order in a voice > call, using a single HTTP/3 Connection. > > > > On Fri, Jul 24, 2020 at 4:30 AM virat tara wrote: > >> Hi Bernard, >> >> >>> Note that the Http3Transport constructor doesn't have an optional >>> QuicTransport object as an argument, so that there's no way to "share" a >>> QUIC transport between Http3 (as used by say, fetch) and Http3Transport. >>> >> >> I got the impression that HTTP/3 calls like fetch and Http3Transport will >> be able to share a connection from >> draft-vvv-webtransport-http3-02#section-1 >> where >> it says "Using the mechanism described here, multiple Http3Transport >> instances can be multiplexed simultaneously with regular HTTP traffic on >> the same HTTP/3 connection". >> >> The ability to share a QUIC connection between HTTP3 (e.g. fetch) and >>> WebTransport (via WebTransport API) has come up from time to time. Do you >>> have a use case where this would be valuable? >>> >> >> An example would be an app where full-duplex communication is required >> only at a particular step of the user flow (ex. taxi booking or food >> ordering application), like at the time of live location sharing or chat >> support, but the rest of the functionality requires only client to server >> API calls. Some of these actions can be simultaneously performed by the >> user like live location sharing + browsing through the app and thus making >> some fetch calls. >> >> One can argue that the fetch calls being stateless can be converted >> into events to make them compatible with WebTransport. I think that's not a >> simple decision to make once you have built up an application and later on >> decide to incorporate a small feature that requires full duplex >> communication on the same server. One can always resort to HTTP Long >> Polling in such cases and I think this is one of the main reasons long >> polling is still in use and not obsolete. RFC 8441 >> would have made it obsolete but it >> is yet to be rolled out on major browsers. >> >> On Fri, Jul 24, 2020 at 7:12 AM Bernard Aboba >> wrote: >> >>> Martin said: >>> >>> "That's a good point. My understanding of the HTTP mappings is that you >>> can make several "instances" of the WebTransport thing in the one >>> connection." >>> >>> [BA] Here is the current Http3Transport constructor: >>> >>> [Exposed =(Window,Worker)]interface Http3Transport { >>> constructor(DOMString url ); >>> }; >>> >>> >>> It only takes a url as an argument (like the WebSocket constructor). So >>> the implication is that invoking the constructor creates a distinct QUIC >>> connection. But using that QUIC connection, it is possible to create >>> multiple bi-directional or uni-directional streams or send datagrams in >>> either direction. So "pooling" or other sharing of an Http3Transport is >>> already supported to a significant extent. >>> >>> Martin said: >>> "Even if you only have one WebTransport thing, you can still use the >>> same connection for HTTP and the thing." >>> >>> [BA] Note that the Http3Transport constructor doesn't have an optional >>> QuicTransport object as an argument, so that there's no way to "share" a >>> QUIC transport between Http3 (as used by say, fetch) and Http3Transport. >>> >>> There is a reason why this isn't supported, even though it was something >>> that seemed quite desirable. HTTP/3 is very specific on how it uses Stream >>> IDs, so it would be quite tricky to have both the WebTransport and another >>> API like fetch sharing a QUIC connection. >>> >>> >>> >>> On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson >>> wrote: >>> >>>> On Fri, Jul 24, 2020, at 04:33, virat tara wrote: >>>> > For an app that would use both regular HTTP calls and WebTransport, >>>> > from the server's perspective, won't using HttpTransport instead of a >>>> > dedicated connection like in QuicTransport help it to reduce the >>>> number >>>> > of active connections/sockets per client? Thus allowing it to serve >>>> > more distinct clients per server. Particularly for apps that make >>>> > occasional HTTP calls and heavily rely on a full-duplex protocol for >>>> > the rest of their working. >>>> >>>> That's a good point. My understanding of the HTTP mappings is that you >>>> can make several "instances" of the WebTransport thing in the one >>>> connection. Even if you only have one WebTransport thing, you can still >>>> use the same connection for HTTP and the thing. With a dedicated >>>> transport, it seems like you just have one. >>>> >>>> Of course that one is capable of a lot of concurrency, so you might be >>>> comfortable with not having multiple sessions, but I can imagine cases for >>>> sharing different logical contexts that can be split at a gateway. >>>> >>>> -- >>>> Webtransport mailing list >>>> Webtransport@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webtransport >>>> >>> -- >>> Webtransport mailing list >>> Webtransport@ietf.org >>> https://www.ietf.org/mailman/listinfo/webtransport >>> >> --0000000000006e5a9105ab6870e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Bernard's question: In this use case, is the= re an interaction between HTTP/3 traffic and WebTransport traffic?=C2=A0 Fo= r example, in the RIPT BOF there were examples shown where an HTTP/3 Reques= t elicited an HTTP/3 Response as well as HTTP/3 datagram traffic from serve= r to client.=C2=A0 The idea was to enable SIP-like exchanges to occur withi= n HTTP/3 so as to enable calling.

    No, there is no interaction between HTTP/3 traffic and= WebTransport traffic in my use case.=C2=A0

    This would enable the taxi booking or food ordering application to al= low the user to talk to the taxi driver or submit their food order in a voi= ce call, using a single HTTP/3 Connection.

    <= div>Yes, this can be another use case where sharing of connection between H= TTP/3 and Http3Transport=C2=A0(via RIPT)=C2=A0will be helpful.
    <= /div>

    On Sat, Jul 25, 2020 at 9:40 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:<= br>
    Virat said:=C2=A0

    =
    "I got the impression that HTTP/3 calls like fetch and Http3Trans= port will be able to share a connection from=C2=A0= draft-vvv-webtransport-http3-02#section-1=C2=A0where it says "Using the= mechanism described here,=C2=A0multiple Http3Transport instances can be = multiplexed simultaneously=C2=A0with regular HTTP traffic on the same HTT= P/3 connection".

    [BA] The WebTransport= API spec seems to imply some (or maybe all) of this, but there isn't a= ny implementation experience AFAIK.

    "An examp= le would be an app where full-duplex communication is required only at a pa= rticular step of the user flow (ex. taxi booking or food ordering applicati= on), like at the time of live location sharing or chat support, but the res= t of the functionality requires only client to server API calls. Some of th= ese actions can be simultaneously performed by the user like live location = sharing=C2=A0+ browsing through the app and thus making some fetch calls.&q= uot;=C2=A0

    [BA] Question: In this use case, is the= re an interaction between HTTP/3 traffic and WebTransport traffic?=C2=A0 Fo= r example, in the RIPT BOF there were examples shown where an HTTP/3 Reques= t elicited an HTTP/3 Response as well as HTTP/3 datagram traffic from serve= r to client.=C2=A0 The idea was to enable SIP-like exchanges to occur withi= n HTTP/3 so as to enable calling.=C2=A0

    This would= enable the taxi booking or food ordering application to allow the user to = talk to the taxi driver or submit their food order in a voice call, using a= single HTTP/3 Connection.



    On Fri, Jul 2= 4, 2020 at 4:30 AM virat tara <virattara@gmail.com> wrote:
    Hi Bernard,
    =C2=A0
    Note th= at the Http3Transport=C2=A0 constructor doesn't have an optional QuicTr= ansport object as an argument, so that there's no way to "share&qu= ot; a QUIC=C2=A0transport between Http3 (as used by say, fetch) and Http3Tr= ansport.

    I got the impression that HTTP= /3 calls like fetch and Http3Transport will be able to share a connection f= rom=C2=A0draft-vvv-webtransport-http3-02#section-1= =C2=A0where it says "Using the mechanism described here,=C2=A0multipl= e Http3Transport instances can be multiplexed simultaneously=C2=A0with re= gular HTTP traffic on the same HTTP/3 connection".
    The ability to share a QUIC connection between HTT= P3 (e.g. fetch) and WebTransport (via WebTransport API) has come up from ti= me to time. Do you have a use case where this would be valuable?

    An example would be an app where full-duplex comm= unication is required only at a particular step of the user flow (ex. taxi = booking or food ordering application), like at the time of live location sh= aring or chat support, but the rest of the functionality requires only clie= nt to server API calls. Some of these actions can be simultaneously perform= ed by the user like live location sharing=C2=A0+ browsing through the app a= nd thus making some fetch calls.

    One can argue tha= t the fetch calls being stateless can be converted into=C2=A0events to make= them compatible with WebTransport. I think that's=C2=A0not a simple de= cision to make once you have built up an application and later on decide to= incorporate a small feature that requires full duplex communication on the= same server. One can always resort to HTTP Long Polling in such cases and = I think this is one of the main reasons long polling is still in use and no= t obsolete.=C2=A0RFC 8441 would have made it obsolete but it is yet to be rolled= out on major browsers.

    On Fri, Jul 24, 2020= at 7:12 AM Bernard Aboba <bernard.aboba@gmail.com> wrote:
    Martin said:=C2=A0=

    "That's a good point.=C2=A0 My understanding o= f the HTTP mappings is that you can make several "instances" of t= he WebTransport thing in the one connection."

    [BA] Here is the current Http3Transport=C2=A0constructor:=C2=A0
    = 
    [Exposed=3D(Window,Worker)]
interface Http3Transport {
  constructor=
(DOMString<=
/span> url<=
/span>)=
;
};

    It only takes a url as an argument (like = the WebSocket constructor).=C2=A0 So the implication is that invoking the c= onstructor creates a distinct QUIC connection.=C2=A0 But using that QUIC=C2= =A0connection, it is possible to create multiple bi-directional or uni-dire= ctional streams or send datagrams in either direction.=C2=A0 So "pooli= ng" or other sharing of an Http3Transport is already supported to a si= gnificant extent.=C2=A0

    Martin said:=C2=A0
    "Even if you only have one WebTransport thing, you can still use th= e same connection for HTTP and the thing."=C2=A0

    <= div>[BA]=C2=A0 Note that the Http3Transport=C2=A0 constructor doesn't h= ave an optional QuicTransport object as an argument, so that there's no= way to "share" a QUIC=C2=A0transport between Http3 (as used by s= ay, fetch) and Http3Transport.

    There is a reason w= hy this isn't supported, even though it was something that seemed quite= desirable. HTTP/3 is very specific on how it uses Stream IDs, so it would = be quite tricky to have both the WebTransport and another API like fetch sh= aring a QUIC connection.=C2=A0


    =

    On Thu, Jul 23, 2020 at 4:58 PM Martin Thomson <mt@lowentropy.net> = wrote:
    On Fri, Jul 24, 2020, at 04:33, virat tara= wrote:
    > For an app that would use both regular HTTP calls and WebTransport, > from the server's perspective, won't using HttpTransport inste= ad of a
    > dedicated connection like in QuicTransport help it to reduce the numbe= r
    > of active connections/sockets per client? Thus allowing it to serve > more distinct clients per server. Particularly for apps that make
    > occasional HTTP calls and heavily rely on a full-duplex protocol for <= br> > the rest of their working.

    That's a good point.=C2=A0 My understanding of the HTTP mappings is tha= t you can make several "instances" of the WebTransport thing in t= he one connection.=C2=A0 Even if you only have one WebTransport thing, you = can still use the same connection for HTTP and the thing.=C2=A0 With a dedi= cated transport, it seems like you just have one.=C2=A0

    Of course that one is capable of a lot of concurrency, so you might be comf= ortable with not having multiple sessions, but I can imagine cases for shar= ing different logical contexts that can be split at a gateway.

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --0000000000006e5a9105ab6870e7-- From nobody Mon Jul 27 05:21:23 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365A43A0DD9 for ; Mon, 27 Jul 2020 05:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 iMHPJO-J8YG6 for ; Mon, 27 Jul 2020 05:21:18 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 5A6803A1916 for ; Mon, 27 Jul 2020 05:21:18 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q7so16990473ljm.1 for ; Mon, 27 Jul 2020 05:21:18 -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=g8japqi3JfjTtFI9w/NXv1nO9ztuzr0xPaWzgk5WAns=; b=ArxYBRdlO/NYDCWd164IsMM9fiiCJNHwDpApzbNIVZXVA3UG+BiNpz24xJrCNs8Z1f Ghjyv2aYO45kA8zzeSc2ClS1sxRD5gPJlJAtwrJsNIp902J3KKU4jpiNPHsfFLNmav+o twlLnRfN1o6tREhLw/T29QBA1TOsBsfVsgXRzPlj2OJxri+anEHNylPr+0EXzgNdblJ4 wsn1r5zVW/WokFoyNh/+OmLB/ofxG4h089F1919V+ZphJyfQO17H+q6fcQDvb6gFK9Xc jalWJF/enlTsoz04RS/gEsWT9SOL66hJtxpb4foGhf7tki4oZOBhcHjbHWY8fWTX42sd R3BQ== 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=g8japqi3JfjTtFI9w/NXv1nO9ztuzr0xPaWzgk5WAns=; b=afmYHXvnb9zodqzU1573F2aB53e3+1WoF3An5rxcacs5GRzWS4Gq0ulSNoZ6GGjWLs 80vB+Ok3BOkLem5So3w8bi8b8LeVMBy0HUvFEpMWEI9PbHszCS1nycoxgwQYhq1EGgAT ucqANIr+ws8DkKnwMrVJwM8fFG9iJPGNoFimEmS46qX3hzDXmOGFpSOAon+CiZUguzjK 73yeekNGy2cFRrxGb90kL4FVU1Qko9JuOg4yy2Is4rovmBq+Wcgj76evujB0yhWN1Ofj b3+/fiVaIBD6ycSKQdH1vlOXsty6pGZfQYG5YvuVvgN+9/CBeA9iHJ8E0i++RTafnFSC nkzA== X-Gm-Message-State: AOAM530gHvVhUQ1FUtvptC8yvTZt3jiMd8N5gBeN7fK8O1ex4/Nj1ow5 Ll8pZvTy4izciDIp+TH/pChxNEx/qvjrr/WVHvE= X-Google-Smtp-Source: ABdhPJxxFEDbA8fdPKJbxnrX/CmFcrnp2qypC3AOTJiPImIYOsWO0URjhUa/kDD8nfH2ama85lFbbV43znTY0oSgCBI= X-Received: by 2002:a2e:92c4:: with SMTP id k4mr2094657ljh.238.1595852476290; Mon, 27 Jul 2020 05:21:16 -0700 (PDT) MIME-Version: 1.0 References: <3084C7A6-B2C3-4C44-A567-3178FEC45C6B@gmail.com> <2b7f05a8-2b6c-231f-7f95-b18462261bdb@gmail.com> In-Reply-To: <2b7f05a8-2b6c-231f-7f95-b18462261bdb@gmail.com> From: Bernard Aboba Date: Mon, 27 Jul 2020 05:21:05 -0700 Message-ID: To: Lennart Grahl Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000f69a7305ab6b5bd2" Archived-At: Subject: Re: [Webtransport] Does WebTransport need a reliable, in-order message abstraction? X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 12:21:21 -0000 --000000000000f69a7305ab6b5bd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Lennart. "And I want to emphasize again on the naming in the API. So far, these are all byte steams we're talking about in the WebTransport API but when adding "message" streams, this isn't clear any more. To quote myself in above linked issue: > [...] I think it makes sense to incorporate the type of stream into the interface in general to avoid confusion in a dynamically typed language (what kind of stream is this? a stream of bananas?) [...]" [BA] This problem exists now in the API document, even without support for messages. For example, receiveStreams() returns a ReadableStream of receiveStreams; receiveBidirectionalStreams() returns a ReadableStream of BidirectionalStreams; readDatagrams() returns a ReadableStream of Uint8Arrays. Yet the WebIDL just says "ReadableStream", with no indication of the kind of stream returned. On Mon, Jul 27, 2020 at 1:16 AM Lennart Grahl wrote: > > > On 26/07/2020 02:08, Bernard Aboba wrote: > > Alan said: > > > >> Is replacing WebSockets with WebTransport one of our goals? If so, I > think we need to address the gap by adding this abstraction. If not, we > should explicitly mention that this abstraction doesn=E2=80=99t exist, an= d instruct > developers to use WebSocket instead. > > > > [BA] Thanks for bringing this up. > > > > When we first started on what would become the RTCQuicTransport API, th= e > goal was to support all the transport modes of the RTCDataChannel API, > which was modelled after WebSockets. > > > > However, we realized that this required design of a framing protocol on > top of QUIC reliable streams. After verifying that a simple framing > protocol was implementable as a JS library on top of the RTCQuicTransport > prototype, providing many of the services of RTCDataChannel, the =E2=80= =9Cproof of > concept=E2=80=9D was considered done and since then not much has happened= . > > > > This is a good example of how things can fall between the cracks of > protocol design and API design. =E2=80=9CAssume we have a framing protoco= l designed > in IETF....=E2=80=9D > > Perhaps a clearly defined framing protocol for WebTransport on top of > those protocols that need it is not a bad idea if it's simple and easily > negotiable. But beyond that, I urge to always think about the > entry-barrier for non-web implementations before adding more protocols. > Because that was one of the top arguments when it came to why supporting > data channels and SCTP in non-web implementations is a problem. > > But back to the "message" feature: I did make a proposal on that to make > the API future-proof for message streams (i.e. stream of byte stream): > https://github.com/WICG/web-transport/issues/49 > If we do have a framing protocol, then it can be easily combined with > the API proposal. > > And I want to emphasize again on the naming in the API. So far, these > are all byte steams we're talking about in the WebTransport API but when > adding "message" streams, this isn't clear any more. To quote myself in > above linked issue: > > > [...] I think it makes sense to incorporate the type of stream into the > interface in general to avoid confusion in a dynamically typed language > (what kind of stream is this? a stream of bananas?) [...] > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000f69a7305ab6b5bd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks, Lennart.=C2=A0

    "And I want to emphasize again on the naming in the API. So far, thes= e
    are all byte steams we're talking about in the WebTransport API bu= t when
    adding "message" streams, this isn't clear any more= . To quote myself in
    above linked issue:

    > [...] I think it ma= kes sense to incorporate the type of stream into the interface in general t= o avoid confusion in a dynamically typed language (what kind of stream is t= his? a stream of bananas?) [...]"

    [BA] Th= is problem exists now in the API document, even without support for message= s.=C2=A0

    For example, receiveStreams() returns a R= eadableStream of receiveStreams; receiveBidirectionalStreams() returns a Re= adableStream of BidirectionalStreams; readDatagrams() returns a ReadableStr= eam of Uint8Arrays.=C2=A0 Yet the WebIDL just says "ReadableStream&quo= t;, with no indication of the kind of stream returned.
    On Mon, J= ul 27, 2020 at 1:16 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:


    On 26/07/2020 02:08, Bernard Aboba wrote:
    > Alan said:
    >
    >> Is replacing WebSockets with WebTransport one of our goals?=C2=A0 = If so, I think we need to address the gap by adding this abstraction.=C2=A0= If not, we should explicitly mention that this abstraction doesn=E2=80=99t= exist, and instruct developers to use WebSocket instead.
    >
    > [BA] Thanks for bringing this up.
    >
    > When we first started on what would become the RTCQuicTransport API, t= he goal was to support all the transport modes of the RTCDataChannel API, w= hich was modelled after WebSockets.
    >
    > However, we realized that this required design of a framing protocol o= n top of QUIC reliable streams. After verifying that a simple framing proto= col was implementable as a JS library on top of the RTCQuicTransport protot= ype, providing many of the services of RTCDataChannel, the =E2=80=9Cproof o= f concept=E2=80=9D was considered done and since then not much has happened= .
    >
    > This is a good example of how things can fall between the cracks of pr= otocol design and API design. =E2=80=9CAssume we have a framing protocol de= signed in IETF....=E2=80=9D

    Perhaps a clearly defined framing protocol for WebTransport on top of
    those protocols that need it is not a bad idea if it's simple and easil= y
    negotiable. But beyond that, I urge to always think about the
    entry-barrier for non-web implementations before adding more protocols.
    Because that was one of the top arguments when it came to why supporting data channels and SCTP in non-web implementations is a problem.

    But back to the "message" feature: I did make a proposal on that = to make
    the API future-proof for message streams (i.e. stream of byte stream):
    https://github.com/WICG/web-transport/issues/49 If we do have a framing protocol, then it can be easily combined with
    the API proposal.

    And I want to emphasize again on the naming in the API. So far, these
    are all byte steams we're talking about in the WebTransport API but whe= n
    adding "message" streams, this isn't clear any more. To quote= myself in
    above linked issue:

    > [...] I think it makes sense to incorporate the type of stream into th= e interface in general to avoid confusion in a dynamically typed language (= what kind of stream is this? a stream of bananas?) [...]

    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --000000000000f69a7305ab6b5bd2-- From nobody Mon Jul 27 06:12:23 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B8B3A1970 for ; Mon, 27 Jul 2020 06:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 Ch63vW1Td2VO for ; Mon, 27 Jul 2020 06:12:19 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 CE4FF3A196C for ; Mon, 27 Jul 2020 06:12:18 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h19so17137175ljg.13 for ; Mon, 27 Jul 2020 06:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=fOBMeEKBHcNOqTkPaPG3TXaA01N9nGZDtruggWLoATw=; b=spLyGChCkH5FBESJyyROtaPwYtcJ/5JrHKNVwunJ3rfzozJxqhuZPVdWR4/X63fdrS 5HP13s2b4j7sdrIz81kEqAmZaheCRbMvPJbm9q6CHMmETRz3ecn66WskCsjbEK0omk4B asfHmMTDajqk4i7bgArIbd/0CyVVg1MLp7MVDly9SqhX/riV1cDYxn+wOZCApNgu8P0s S/TYRncLH2+koJ+HxwfhJeVp/unwcV1ssjoHWMFkTDu1tVWWoiFZGpcUxIb3cTt/Hvpk 7/UHehGGlnAR4PIjEfoUiCHcJwl+6cYgm079/X9qfXjuhF159969ZJGYCw3sB1BZ3STw Fqqg== 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; bh=fOBMeEKBHcNOqTkPaPG3TXaA01N9nGZDtruggWLoATw=; b=BMRBykwOE1m0BR4UA+ObZyspSZKI0f6mogvwKcO8/wNY6SwacLU/zy36DJB+9+BRnW //aHk2dMwYu23yeyu6TajnefjSbl8U8mJJg1t41301ywpVaykp2CWOJyhIEZfGXUzwze /87UbAuRgUaZ0rhF18Y12TosocVmKgovar1O/hy/u4k1WAvsluTsGqlw5ZGJsYTAA6O5 hm/WaeSqvQ6/tlzs5L/1r5XI6JoCyzFwfqNGsHgEVqmbRzmgLXL+9+yuI5/NCBeCEiqX 7EKAJpBV8LYfaw0Y+/l76eQALmyz0SVsFfXRPm4uzxUhchHISMFBesJkPwNKfKzdptAA 5oIA== X-Gm-Message-State: AOAM530sYk/bMuJrp436BVP9+eNeQoygos3YgfMJytCAtrzAT6q0r9uZ DdhLqtG8pwtW9SB9NYsUgzRHMWNb/BXygPya35IDwmK4 X-Google-Smtp-Source: ABdhPJw6raofZlE3pQqiCjdO44CktX7VEIjof8MlMNX9GC4st0uyH5E7Cy+/wRqcg0nqTwcHQB5OaUS3B0ssr7LwJyU= X-Received: by 2002:a05:651c:3c2:: with SMTP id f2mr10484604ljp.37.1595855536446; Mon, 27 Jul 2020 06:12:16 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 27 Jul 2020 06:12:05 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="0000000000005cf93105ab6c1250" Archived-At: Subject: [Webtransport] IETF 108 slides X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 13:12:21 -0000 --0000000000005cf93105ab6c1250 Content-Type: text/plain; charset="UTF-8" Should be available on the meeting materials site: https://datatracker.ietf.org/meeting/materials/ And also can be viewed here: https://docs.google.com/presentation/d/1cr_4jtUCYTkoJQl4jEWT9LKJfZkkYM1W3MW8s2bz47Y/ --0000000000005cf93105ab6c1250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Should be available on the meeting materials site:=C2=A0https://data= tracker.ietf.org/meeting/materials/

    And also can= be viewed here:=C2=A0
    --0000000000005cf93105ab6c1250-- From nobody Mon Jul 27 07:06:33 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9B33A19AE for ; Mon, 27 Jul 2020 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 QHrUcngx7b3r for ; Mon, 27 Jul 2020 07:06:30 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 70E243A19B8 for ; Mon, 27 Jul 2020 07:06:16 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id r19so17330051ljn.12 for ; Mon, 27 Jul 2020 07:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MkZ0uxAcZxk+xS7r7+pH6S9RuF6NPHlFos/Q0DD6+4Y=; b=ED2bJ6AAaM4JY0+QaevbekiWz3LN2AW1m/dXYzUnmPHWerakQg3fhrtxCE6Sz15uG5 TVl6AO4kUIBVMp0klnhJEcvs4GbEdvzdo6AGSmsiHA52V3GssPvpehsGOoitWWzomOGp znuxF6CpBgZVUWXT/3UmDwlM455VcbDqQtM6V4fZyN8/Vj7/Vm2j4j2F8tc2LazVOznl tQL4Oyj9C9kF02veZhHbNW+8eUrgD/GxSmVTqgHgS8mVK9lipCMujfyK7QCwithJsyPT BB7hVh9XpzfW0CBLItKMhLBQQnfF0w3oVA5jVvPFlrKrvChxCPhee1NT+pA7x2M1Cifu OPWg== 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; bh=MkZ0uxAcZxk+xS7r7+pH6S9RuF6NPHlFos/Q0DD6+4Y=; b=qalcnTE7cSPdW872rqxoc2/joaXmHi+y6L0njcAu8eWOGKv8cYcPwncxkQVodbK0zF AdqB5uRz/O1TS+l8kqV9PrEAsKaJmnd/wTP7RsZc+5cwu3JJlxYBoxtF7vU9wHkb4liL 4bU4L+2GNvkxqXY8A/LH1qnodUdDly5Bx7qcfbVIDBGxc81Zkvv626Qh4dT074zU/qlr i1RJzUo45ASipbzM61QfaGaa8pEPNfb0JnxZmSdOM+dOm6SkTJ0lJce69batBQYgx/RH x1CvmMnlhd1SCkvLaTSrs+m9hEiUSm6MeGI/yJ6TEegtTFTzThkPEVY4fnDVTRDzBcuB uhAQ== X-Gm-Message-State: AOAM530HY5oyhD1NJ+rF34RpWNs3amByIBJRo3BcFc34PEhvMA9qHmBK MmXNszV/a4lPcrehtyOcgCDh/pzBAWrSX/IVyQ+oWiBx X-Google-Smtp-Source: ABdhPJwy/K7avz94ZhgPxpdifUYXdEAnLF6VHkAKnEKx9J0X3RrcIqx9ken3Q82X/xihw1FXVWLqbpDC3LrghgVRK1s= X-Received: by 2002:a05:651c:3c2:: with SMTP id f2mr10589473ljp.37.1595858774060; Mon, 27 Jul 2020 07:06:14 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 27 Jul 2020 07:06:03 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="00000000000056f5e805ab6cd3f8" Archived-At: Subject: [Webtransport] IETF 108 WebTransport WG Meeting X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 14:06:32 -0000 --00000000000056f5e805ab6cd3f8 Content-Type: text/plain; charset="UTF-8" will be starting in a few minutes. The meeting is being hosted in MeetEcho, which operates somewhat differently from WebEx, which we used for IETF 107. Documentation on IETF 108 MeetEcho usage is here: https://www.ietf.org/media/documents/Documentation-Meetecho-IETF.pdf A few tips: - IETF 108 registration and a datatracker account is required to join the meeting. - Your name will be automatically added to the attendee list based on your datatracker login. - Join the session Jabber room via IETF Datatracker Meeting agenda - When entering the queue, you need to select audio, video or both. - When you are called on, you need to enable your audio to be heard. - Please use headphones when speaking. - Please state your full name before speaking. --00000000000056f5e805ab6cd3f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    will be starting in a fe= w minutes.=C2=A0

    The meeting is being hosted in MeetEcho= , which operates somewhat differently from WebEx, which we used for IETF 10= 7.=C2=A0

    Documentation on IETF 108 MeetEcho usage = is here:=C2=A0

    A few tips:

    • IETF 108 r= egistration and a datatracker account is required to join the meeting.=C2= =A0

    • Your name will be automatically added to= the attendee list based on your datatracker login.

    • Join the session Jabber room via IETF Datatracker Meeting agenda

    • When entering the queue, y= ou need to select audio, video or both.

    • <= p dir=3D"ltr" style=3D"line-height:1.32;margin-top:0pt;margin-bottom:0pt"><= span style=3D"color:rgb(0,0,0);background-color:transparent;font-variant-nu= meric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-s= pace:pre-wrap">When you are called on, you need to enable your audio to be = heard.

    • Please use headpho= nes when speaking.

    • Plea= se state your full name before speaking.

    <= /div>
    --00000000000056f5e805ab6cd3f8-- From nobody Mon Jul 27 11:13:27 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6E3A1BF4 for ; Mon, 27 Jul 2020 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 UeO40w8BE5JF for ; Mon, 27 Jul 2020 11:13:17 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 3381F3A1C1C for ; Mon, 27 Jul 2020 11:13:17 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t6so5358076ljk.9 for ; Mon, 27 Jul 2020 11:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=w81dxB3HyT0VZlnhKZ+ripLpmm3w/4Aq3e7s76SQDXQ=; b=nLal17VidSSH1smrjjbjuoyENI+FrgzDA9xsV2QG6V2W4+vKO72SN2mJyuayrl9ShL SeGGO+7lAcisTNM5sEKoNw7aROLR7MtIPUr++gx+RwnjSUDvqGQDVjVDstdfd3ernxbg aApdAtnyfvJXkHUsejcT2fieAMnNa+5fcrE61wqytUNxHyWlADR5Rtnzz8QJ8X+OrBtR 55/RmaS1ZkQzvcyvRcl2vYIaN7y8szzH1TS4aq68EJYCyl1dd0D1bz0AXuHVezqEml/o mv+O3y/ZUs+L+EnxSKxzQwb0HIVmsrQPVST8p0vdUgslVnoh6oL8Mrytig9kO+Y8Je1n uYnA== 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; bh=w81dxB3HyT0VZlnhKZ+ripLpmm3w/4Aq3e7s76SQDXQ=; b=iEAT/9B2J3JAN78xh9H+ehDaTeu/SYbnccns7ZQKYtiHjZy2nJ5toU/mst0dtwk3u0 MJgGycQSIuDn3sIWzr4i4BKdEqJRVj43Ursgi3Ebd0vGuVCi2+N/+FgAo3Sd06yaRzri KcUdWkmh7lWZbN+kA7yvk1DEZiKklSEg+MMYJv7co4G3dhazOF9gn3POPDyv4shtK/4B m1o6vW0ZD3+V3Vw+maO+O4LOi/bhkoWkIxCgabnXHnbsGjN6RHsBAZvEzCuf2hiGPXub V+pIEdfDVAzmLL9uA083W2h1Mv/TQP6Y+OHiY50XO9e8HJ3q331/sbnHap3hdetv7NaW h/zg== X-Gm-Message-State: AOAM533EMs0pITq86am4pjvs4QoF27BB1P+1R+Te6Dm8ur1Vfi1T3z1W hlVdWcAn70zx8NPvfPlBhnN3SxWCA443/A/hZV+8X/Fu X-Google-Smtp-Source: ABdhPJzsX2CsJ/Kpu69arv8bQJBJ4Go6ui2bM7BeFXR3e8ELXKO2CI9G4umVecGJrLiQqqurA05VuLA7Sg2wd7n8pEo= X-Received: by 2002:a2e:8783:: with SMTP id n3mr9763238lji.317.1595873594930; Mon, 27 Jul 2020 11:13:14 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 27 Jul 2020 11:13:04 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000bb9afd05ab7046db" Archived-At: Subject: [Webtransport] Minutes of the IETF 108 WEBTRANS WG Meeting X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 18:13:24 -0000 --000000000000bb9afd05ab7046db Content-Type: text/plain; charset="UTF-8" Have been uploaded here: https://datatracker.ietf.org/doc/minutes-108-webtrans/ Many thanks to the Jabber Scribe (Spencer Dawkins) and the Note Takers (Lucas Pardue, Amelia Andersdotter and Eric Kinnear) --000000000000bb9afd05ab7046db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Have been uploaded here:=

    <= /div>
    Many thanks to the Jabber Scribe (Spencer Dawkins) and the Note T= akers (Lucas Pardue, Amelia Andersdotter and Eric Kinnear)
    --000000000000bb9afd05ab7046db-- From nobody Mon Jul 27 13:13:02 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0AA3A0BA8 for ; Mon, 27 Jul 2020 13:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 1lkbxW8OJaxH for ; Mon, 27 Jul 2020 13:12:51 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 0AECA3A0BA9 for ; Mon, 27 Jul 2020 13:12:51 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id q6so18648102ljp.4 for ; Mon, 27 Jul 2020 13:12:50 -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=qFSg9b6W1rBVOvcCQRybYDuGgnY6775fzh6Ii/XQQQQ=; b=okUHyWHMZnceguCqKm3DGMp6TbpdcvKXcEvZYeqz3Kqaqmk9tSrGKyd0kQ+9aPLdG+ TE9ZDNVpUmhwsFUa+ri7t/6BIXVpkc7EUdpclxQ59Zh6pZ2XgAhKmbZGzIy91Xb+6ekR LrjJQhAh8Vt33uSZrz+JG3q9JKYjAXorzDJBe2BGkYcAdd8ifFiEv5C4RICTV/1r2Rx1 mOnWzK/z2tcCcTTEPMPRpUw1PgSmBHu9B4nE8h/WIL74mRaMX1EpoSyXEJUAAR+aZUOT jDwKiHb0HYEhorzCMFSj3AenW2CPV2cXBeL8lidCH6CYJOvNglEAbeIreSvn8WrPkr6E J2Ug== 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=qFSg9b6W1rBVOvcCQRybYDuGgnY6775fzh6Ii/XQQQQ=; b=i/ugP2EgEXdhUvet9XZsgoHc3vdkSubWtA/dXJ4wz0/PMKIjOPXDIIETqIWhBZd1HJ 31WowAhkkiKdNn5gISlFxVqkok+LoB2l1ERwxt81N3bY1HN3Hg/u+wfmjwJjnlxv5zOo KqDhyUnjaUZTEfjsQVA5DFvAf1qmdC+q83OSy5p0BkTZj2Us9xKo4gv0cmpds9c++SgF 4s4ox9l56pzBZIW6467KxpL5Brhv46UHVeebOSho1ZrZuaJUvc+RlVwISXeBLPVvfY/1 LbrerqqOtpiZJviSe8A0aexX2CEfS9xb8ykmLIsJpFrq1pOlslSY3ZY61wRgNILVQcMQ W7BQ== X-Gm-Message-State: AOAM531ljZHMDv73fM9LtLNsNTYmjX5qqRDsFmZOzLcBIsiDe1CMrYyb KxnDv36o6LTZ2+IYksddpz6uBQoJKs5Wjp8T5Ns= X-Google-Smtp-Source: ABdhPJytB9uH40IUyXUb2IZB8McPJJ/G51TMaDmqpsYhBo0+A29B3hYppXxFYxmwiEsjH4Ma+LOPk7bTHkCLsEGgWTk= X-Received: by 2002:a2e:9a4d:: with SMTP id k13mr11405845ljj.283.1595880769046; Mon, 27 Jul 2020 13:12:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Mon, 27 Jul 2020 13:12:37 -0700 Message-ID: To: Yutaka Hirano Cc: WebTransport , Ted Hardie Content-Type: multipart/alternative; boundary="00000000000057cb7e05ab71f24c" Archived-At: Subject: Re: [Webtransport] Choosing the Transport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 20:13:01 -0000 --00000000000057cb7e05ab71f24c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "If we decide that QuicTransport is a way to go, we=E2=80=99d have to add m= ore features into its handshake, since I suspect most people won=E2=80=99t be h= appy with what=E2=80=99s in there right now " [BA] As Ted noted during the meeting, there are datagram use cases for which "more features" may not be helpful or desirable. At the W3C Games workshop, developers indicated a desire for "UDP for the Web", a way to send small updates client/server or P2P. Another "UDP for the Web" scenarios is video ingest, uploading video from a camera or browser to a server that would prefer not to have to implement ICE or WebRTC. In those kind of scenarios, implementations may not even support all of QuicTransport (e.g. only QUIC datagrams, not reliable streams). So instead of starting from the assumption that "there can only be one", would it be possible to start from the assumption that "simplicity is the main feature" of QuicTransport, leaving the enhancements (and the bulk of WG attention) on Http3/Http2Transport? This is what the IETF did with SLIP (a non-standard) and PPP (standards track). On Mon, Jul 27, 2020 at 12:58 AM Yutaka Hirano wrote: > > If we decide that QuicTransport is a way to go, we=E2=80=99d have to ad= d more > features into its handshake, since I suspect most people won=E2=80=99t be= happy > with what=E2=80=99s in there right now (HTTP headers like Location or For= warded > would be a good example of what people would end up needing in practice, > together with an ability to tag along arbitrary key-value metadata for > debugging purposes). If we decide that HttpTransport is a way to go, we > would have to ensure that the result is easy for Web developers to use, a= nd > that we understand the differences between it and regular HTTP. > > Is this for web developers or non-web users? > WebSocket uses the Upgrade mechanism and uses HTTP headers, but doesn't > expose most of the information. For example, we don't expose the HTTP > status code to web developers. The only information it exposes to web > developers is > - whether the connection is established > - protocol (sec-websocket-protocol) > - extensions (sec-websocket-extensions) > . > > I'm a bit concerned about confusion we would see with having yet another > HTTP-like protocol. To what extent it is similar to HTTP is difficult, an= d > people would have diverse expectations I think, given the experience in > WebSocket. > > On Thu, Jul 23, 2020 at 6:23 AM Victor Vasiliev 40google.com@dmarc.ietf.org> wrote: > >> Hello everyone, >> >> We recently adopted the overview draft >> that >> describes the general requirements for and the model of WebTransport. >> However, we haven't yet adopted any specific wire protocol proposals. >> There are currently three of those presented to the working group: >> >> - QuicTransport >> >> - Http2Transport >> >> - Http3Transport >> >> - [hypothetical WebTransport over WebSocket] >> >> Back when the original idea of WebTransport was forming, the hope was to >> implement and ship all four of those, since they all fit different use >> cases better. After talking more to the people at IETF, it sounds like >> four transports is a bit too much, and we should settle on two (one over >> QUIC, and one over TCP). The natural picks would be either Http3Transpo= rt >> with Http2Transport as fallback (HttpTransport for short), or QuicTransp= ort >> with=E2=80=A6 *something* as a fallback. Let=E2=80=99s look at the diff= erences between >> those two options. >> >> *Differences* >> >> The most substantial wire format difference between those two proposals >> is the handshake. QuicTransport originally did not have any handshake; = we >> had to add a bespoke handshake later in order to implement the Origin >> header, and we also added a Path header later on. We currently don=E2= =80=99t have >> any form of response headers, so if the server is unhappy with the origi= n >> or path received, it has to close the connection with CONNECTION_CLOSE.. >> In HttpTransport, we have regular HTTP header fields for both request an= d >> response, meaning that the server can do things like return a 4xx/5xx fo= r >> an error. >> >> During the connection itself, the difference is minimal: QuicTransport >> uses streams and datagrams as-is, while Http3Transport prefixes everythi= ng >> with an ID, since it is multiplexed with other HTTP traffic. There migh= t >> be a question of whether prefixing can impose undesirable framing overhe= ad; >> I think if that ever becomes a serious problem, we can come up with some >> extension to work this around. >> >> If we decide that QuicTransport is a way to go, we=E2=80=99d have to add= more >> features into its handshake, since I suspect most people won=E2=80=99t b= e happy >> with what=E2=80=99s in there right now (HTTP headers like Location or Fo= rwarded >> would be a good example of what people would end up needing in practice, >> together with an ability to tag along arbitrary key-value metadata for >> debugging purposes). If we decide that HttpTransport is a way to go, we >> would have to ensure that the result is easy for Web developers to use, = and >> that we understand the differences between it and regular HTTP. >> >> From the server complexity standpoint, I am not particularly worried >> about either. We=E2=80=99ve implemented QuicTransport in Chrome, and I = wrote two >> servers for it, in C++ and in Python; the Python one took about 100 line= s >> of code. Http2Transport has been implemented, in somewhat different for= ms, >> by both Apple and Facebook, so we have practical experience with it too.= . >> I was previously concerned that having to implement HPACK/QPACK would be= a >> burden to the Web developers since those are more complex than what you= =E2=80=99d >> typically find in a WebSocket implementation, but now that we have a >> draft to turn compression off >> , I=E2=80=99m les= s >> worried about this. >> >> There is a question of how much of the HTTP ecosystem we would be >> actually getting by adopting HTTP. It is true that basing WebTransport = on >> HTTP does not mean HTTP middleware would automatically implement it. Th= at >> said, we do get a lot of useful features from HTTP, notably message rout= ing >> and a well-understood metadata format. Everyone knows what a code 200 o= r >> 404 is, and a lot of people have built their internal debugging/tracing >> tools based on adding HTTP headers to things, and being able to easily p= ort >> those to WebTransport would be an asset. I=E2=80=99ve seen some argumen= ts that >> content negotiation and caching might be applicable to certain classes o= f >> WebTransport resources too (e.g. a live stream can be cached in the sens= e >> that requesting a live stream is joining it), though those kinds of case= s >> would have to be content-specific and they do not generalize as nicely a= s >> caching for regular HTTP resources. An interesting point to note is tha= t >> WebTransport is always included programmatically (as opposed to being >> navigated to or sourced via URL from HTML), thus alleviating the need fo= r a >> lot of otherwise useful HTTP headers. >> >> *Questions* >> >> While on the surface the question here is =E2=80=9Cwhich drafts should w= e >> adopt?=E2=80=9D, I would like to break this question down into two layer= s: >> >> 1. Do we want to use the wire format in which we try to build >> minimally on top of QUIC (QuicTransport), or do we base it on HTTP? >> 2. To what extent WebTransport connections act like HTTP >> connections? Do they have https URLs or a dedicated schema? Which H= TTP >> headers do and don=E2=80=99t work? >> >> >> Regarding the first issue, I am increasingly leaning towards keeping onl= y >> the HTTP-based option. QuicTransport=E2=80=99s most appealing feature is= its >> simplicity; however, ever since we=E2=80=99ve had to add a header to com= municate >> the Web origin, there has been increasingly more and more reasons to add >> new features to it, so even if we go that way, we=E2=80=99re probably go= ing to end >> up with something that=E2=80=99s a lot like HTTP. Also, we know exactly= how to do >> TCP fallback in this case, so this removes a lot of design problems from >> consideration. Fixing complexity and other problems with HTTP is probab= ly >> more viable. >> >> Regarding the second issue, I am not sure how much of it is in scope for >> this working group.. While we do need to define a URL schema, and the >> choice of schema will give us a lot of answer (by making WebTransport sa= me >> or different origin as HTTP), a lot of those questions have been >> traditionally answered somewhere in Fetch spec, or simply not addressed = in >> the standards at all. I am not quite sure what to do with those. >> >> What do people think? >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --00000000000057cb7e05ab71f24c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    "If we decide that= QuicTransport is a way to go, we=E2=80=99d have to add more features into = its handshake, since I suspect most people won=E2=80=99t be happy with what= =E2=80=99s in there right now=C2=A0"

    [BA] As= Ted noted during the meeting, there are datagram use cases for which "= ;more features" may not be helpful or desirable. At the W3C Games work= shop, developers indicated a desire for "UDP for the Web", a way = to send small updates client/server or P2P.=C2=A0 Another "UDP for the= Web" scenarios is video ingest, uploading video from a camera or brow= ser to a server that would prefer not to have to implement ICE or WebRTC.= =C2=A0

    In those kind of scenarios, implementations= may not even support all of QuicTransport (e.g. only QUIC datagrams, not r= eliable streams).=C2=A0

    So instead of starting fro= m the assumption that "there can only be one", would it be possib= le to start from the assumption that "simplicity is the main feature&q= uot; of QuicTransport, leaving the enhancements (and the bulk of WG attenti= on) on Http3/Http2Transport? This is what the IETF did with SLIP (a non-sta= ndard) and PPP (standards track).=C2=A0


    =

    = On Mon, Jul 27, 2020 at 12:58 AM Yutaka Hirano <yhirano=3D40google.com@dmarc.ietf.org> wrote:=
    > If we decide that QuicTransport is a way to go, we=E2=80=99= d have to add more features into its handshake, since I suspect most people= won=E2=80=99t be happy with what=E2=80=99s in there right now (HTTP header= s like Location or Forwarded would be a good example of what people would e= nd up needing in practice, together with an ability to tag along arbitrary = key-value metadata for debugging purposes).=C2=A0 If we decide that HttpTra= nsport is a way to go, we would have to ensure that the result is easy for = Web developers to use, and that we understand the differences between it an= d regular HTTP.=C2=A0=C2=A0

    Is this for web developers or non-web users?<= /div>
    WebSocket uses the Upgrade mechanism and = uses HTTP headers, but doesn't expose most of the information.=20 For example, we don't expose the HTTP status code to web developers. Th= e only information it exposes to web developers is
    =C2=A0- whether the connection is established
    =C2=A0- protocol (sec-websocket-protocol)
    =C2=A0- extensions (sec-websocket-extensions)
    .

    I'm a bit concerned about confusion we would see = with having yet another HTTP-like protocol. To what extent it is similar to= HTTP is difficult, and people would have diverse expectations I think, giv= en the experience in WebSocket.

    On Thu, Jul 23, 2020 at 6:23 AM = Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
    Hello every= one,

    We recently adopted the overview draft that = describes the general requirements for and the model of WebTransport.=C2=A0= However, we haven't yet adopted any specific wire protocol proposals.= =C2=A0 There are currently three of those presented to the working group:Back when the original idea of WebT= ransport was forming, the hope was to implement and ship all four of those,= since they all fit different use cases better.=C2=A0 After talking more to= the people at IETF, it sounds like four transports is a bit too much, and = we should settle on two (one over QUIC, and one over TCP).=C2=A0 The natura= l picks would be either Http3Transport with Http2Transport as fallback (Htt= pTransport for short), or QuicTransport with=E2=80=A6 something as a= fallback.=C2=A0 Let=E2=80=99s look at the differences between those two op= tions.

    Differences

    The most substantial wire format di= fference between those two proposals is the handshake.=C2=A0 QuicTransport = originally did not have any handshake; we had to add a bespoke handshake la= ter in order to implement the Origin header, and we also added a Path heade= r later on.=C2=A0 We currently don=E2=80=99t have any form of response head= ers, so if the server is unhappy with the origin or path received, it has t= o close the connection with CONNECTION_CLOSE..=C2=A0 In HttpTransport, we h= ave regular HTTP header fields for both request and response, meaning that = the server can do things like return a 4xx/5xx for an error.

    During = the connection itself, the difference is minimal: QuicTransport uses stream= s and datagrams as-is, while Http3Transport prefixes everything with an ID,= since it is multiplexed with other HTTP traffic.=C2=A0 There might be a qu= estion of whether prefixing can impose undesirable framing overhead; I thin= k if that ever becomes a serious problem, we can come up with some extensio= n to work this around.

    If we decide that QuicTransport is a way to g= o, we=E2=80=99d have to add more features into its handshake, since I suspe= ct most people won=E2=80=99t be happy with what=E2=80=99s in there right no= w (HTTP headers like Location or Forwarded would be a good example of what = people would end up needing in practice, together with an ability to tag al= ong arbitrary key-value metadata for debugging purposes).=C2=A0 If we decid= e that HttpTransport is a way to go, we would have to ensure that the resul= t is easy for Web developers to use, and that we understand the differences= between it and regular HTTP.

    From the server complexity standpoint,= I am not particularly worried about either.=C2=A0 We=E2=80=99ve implemente= d QuicTransport in Chrome, and I wrote two servers for it, in C++ and in Py= thon; the Python one took about 100 lines of code.=C2=A0 Http2Transport has= been implemented, in somewhat different forms, by both Apple and Facebook,= so we have practical experience with it too..=C2=A0 I was previously conce= rned that having to implement HPACK/QPACK would be a burden to the Web deve= lopers since those are more complex than what you=E2=80=99d typically find = in a WebSocket implementation, but now that we have a draft to tur= n compression off, I=E2=80=99m less worried about this.

    There is= a question of how much of the HTTP ecosystem we would be actually getting = by adopting HTTP.=C2=A0 It is true that basing WebTransport on HTTP does no= t mean HTTP middleware would automatically implement it.=C2=A0 That said, w= e do get a lot of useful features from HTTP, notably message routing and a = well-understood metadata format.=C2=A0 Everyone knows what a code 200 or 40= 4 is, and a lot of people have built their internal debugging/tracing tools= based on adding HTTP headers to things, and being able to easily port thos= e to WebTransport would be an asset.=C2=A0 I=E2=80=99ve seen some arguments= that content negotiation and caching might be applicable to certain classe= s of WebTransport resources too (e.g. a live stream can be cached in the se= nse that requesting a live stream is joining it), though those kinds of cas= es would have to be content-specific and they do not generalize as nicely a= s caching for regular HTTP resources.=C2=A0 An interesting point to note is= that WebTransport is always included programmatically (as opposed to being= navigated to or sourced via URL from HTML), thus alleviating the need for = a lot of otherwise useful HTTP headers.

    Questions

    Whil= e on the surface the question here is =E2=80=9Cwhich drafts should we adopt= ?=E2=80=9D, I would like to break this question down into two layers:
  • Do we want to use the wire format in which we try to build minimally = on top of QUIC (QuicTransport), or do we base it on HTTP?
  • To what e= xtent WebTransport connections act like HTTP connections?=C2=A0 Do they hav= e https URLs or a dedicated schema?=C2=A0 Which HTTP headers do and don=E2= =80=99t work?

    • Regarding the first issue, I am increasingly lea= ning towards keeping only the HTTP-based option. QuicTransport=E2=80=99s mo= st appealing feature is its simplicity; however, ever since we=E2=80=99ve h= ad to add a header to communicate the Web origin, there has been increasing= ly more and more reasons to add new features to it, so even if we go that w= ay, we=E2=80=99re probably going to end up with something that=E2=80=99s a = lot like HTTP.=C2=A0 Also, we know exactly how to do TCP fallback in this c= ase, so this removes a lot of design problems from consideration.=C2=A0 Fix= ing complexity and other problems with HTTP is probably more viable.
    Regarding the second issue, I am not sure how much of it is in scope for t= his working group..=C2=A0 While we do need to define a URL schema, and the = choice of schema will give us a lot of answer (by making WebTransport same = or different origin as HTTP), a lot of those questions have been traditiona= lly answered somewhere in Fetch spec, or simply not addressed in the standa= rds at all.=C2=A0 I am not quite sure what to do with those.

    What do= people think?
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --
    Webtransport mailing list
    Webtransport@iet= f.org
    https://www.ietf.org/mailman/listinfo/webtransport=
    --00000000000057cb7e05ab71f24c-- From nobody Mon Jul 27 22:16:08 2020 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581873A0C6F for ; Mon, 27 Jul 2020 22:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=XUS4aeTh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BGOZEkSj 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 3w3a_Qjaka-h for ; Mon, 27 Jul 2020 22:16:02 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF173A0C6E for ; Mon, 27 Jul 2020 22:16:02 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id C167C169E for ; Tue, 28 Jul 2020 01:16:01 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 28 Jul 2020 01:16:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=/tXrikArBD71uZNreIFgBrrZOOXrCLG zpByj2nz2Oqk=; b=XUS4aeTht6X39pu9hrj06buVttxEYFwNHiA4NmjlWdrN2CS 7ytZ7msoTHYHi4g2lDFiKCv+abHgJpYV8XcW9uR7EaurUvRz0HI++ErxFIxdXf/w b5wwWkvYuFHHOiMfXrj+lbVxVOOkH+aWsP5xlu8SOMuv+zXOpUm6KXxZb0emw5Ky e6RQQ4Fv4B7RmzBl9At6Ok+lwVBOUdq8S3qvZ4ihSi/SZU+5ufmFclQWi54vq3RO sll8Egnw1774ixWFIP5OJqbKcXnirnEwt/e0K2GzUkA4mqRrE43QAfxGGSoHpgsn gNr/O2XKCrsO27Kvzq2qwWbaPSy9ZHbH7FKu/qQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=/tXrik ArBD71uZNreIFgBrrZOOXrCLGzpByj2nz2Oqk=; b=BGOZEkSjnArI/aM4lYeBsr h7+6Wq+mk2OtrJQCMBahB1JSKzsv9T+7IWZmuBywK/w2KhyFdfdzLuiHpXyUMUoT E1Fen6sy5rcIyV6Syn2dBiYOHLuAYaSVD7dnWUeb8UqLIvUyq0kLLqsEpUmv1lr7 kZDU5EULwUaBVARGYJlt+HQl110O5Dx5KbakhtHU7Z2pzwBAeMdc0MyM/fkhIv4F NaSsVSp7guQTLoOfiNhLpkF+XCWfvwTRO5hXQ2YCpBDyyFBDuid4Khe6F66mQc/U UJo/9fFJnly4qKqTkvrHbNYzFmRpJSCeixokCGKoLOUKTtE8kVBs3ITd5wzdYXJQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedriedugdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfeitddtveeihfejjefgve efuedugffgkeevkeehueeggeelveekveektdfhueeinecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14DA0E00C9; Tue, 28 Jul 2020 01:16:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Jul 2020 15:15:40 +1000 From: "Martin Thomson" To: webtransport@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Webtransport] Minutes of the IETF 108 WEBTRANS WG Meeting X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 05:16:07 -0000 Thanks for the clear minutes. They were a great help. I couldn't see concrete actions, just discussion points. I assume that we'll see follow-up threads here for those topics where there was progress. On Tue, Jul 28, 2020, at 04:13, Bernard Aboba wrote: > Have been uploaded here: > https://datatracker.ietf.org/doc/minutes-108-webtrans/ > > Many thanks to the Jabber Scribe (Spencer Dawkins) and the Note Takers > (Lucas Pardue, Amelia Andersdotter and Eric Kinnear) > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport >