From nobody Sun Oct 18 17:44:36 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 F35803A10F2; Sun, 18 Oct 2020 17:44:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: webtransport@ietf.org Message-ID: <160306827187.29253.8531257358003382553@ietfa.amsl.com> Date: Sun, 18 Oct 2020 17:44:31 -0700 Archived-At: Subject: [Webtransport] I-D Action: draft-ietf-webtrans-overview-01.txt 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: Mon, 19 Oct 2020 00:44:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WebTransport WG of the IETF. Title : The WebTransport Protocol Framework Author : Victor Vasiliev Filename : draft-ietf-webtrans-overview-01.txt Pages : 12 Date : 2020-10-18 Abstract: The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with a model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-webtrans-overview/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-webtrans-overview-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-webtrans-overview-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 12:21:18 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 1393B3A1062; Mon, 19 Oct 2020 12:21:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, webtransport@ietf.org, webtrans-chairs@ietf.org, lflynn@amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160313527700.7512.6505594913647915148@ietfa.amsl.com> Date: Mon, 19 Oct 2020 12:21:17 -0700 Archived-At: Subject: [Webtransport] webtrans - New Meeting Session Request for IETF 109 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: Mon, 19 Oct 2020 19:21:17 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the webtrans working group. --------------------------------------------------------- Working Group Name: WebTransport Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 130 Conflicts to Avoid: Chair Conflict: avtcore dnssd mmusic artarea dispatch Technology Overlap: quic httpbis masque tls People who must be present: Bernard Aboba Barry Leiba 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 Fri Oct 23 14:19:01 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 EFFCD3A11A3; Fri, 23 Oct 2020 14:15:51 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348775197.5087.18133726656018314152@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:51 -0700 Archived-At: Subject: [Webtransport] webtrans - Requested session has been scheduled for IETF 109 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: Fri, 23 Oct 2020 21:15:56 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. webtrans Session 1 (2:00 requested) Monday, 16 November 2020, Session III 1600-1800 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/webtrans.ics Request Information: --------------------------------------------------------- Working Group Name: WebTransport Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 130 Conflicts to Avoid: Chair Conflict: avtcore dnssd mmusic artarea dispatch Technology Overlap: quic httpbis masque tls People who must be present: Bernard Aboba Barry Leiba 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 Mon Oct 26 11:13: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 E9F5E3A0B9C for ; Mon, 26 Oct 2020 11:13:12 -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 qt1IQB_zkwCt for ; Mon, 26 Oct 2020 11:13:11 -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 652AF3A0B9F for ; Mon, 26 Oct 2020 11:13:11 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id c21so11280591ljj.0 for ; Mon, 26 Oct 2020 11:13:11 -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=n31vAJ0/z0WUmY2fan4e0nlYqV/i1KM7kpORiTJw8pE=; b=YY0wbkYr+FLxtMHLTdahnox39zLJykC1bSGX+IJDa1SF+bTU+5Abr2b5/KMdb4L1Hw NDQQif6PQIT8/tsJP2oqvKLRTkRhSIEjzQzufGd6zVz/6+bhptusUc8U+mPTZjE2qu5X ZSXNdD5eyHWDIZ/0AE2e53YvOSQoej5dSBa35pU/0xXhME0M9QGCn4SVXk4O22HzAhKY Sdjpo/j5dox/lko9i1DL3gU+ZWbT1EdoG2ktynM/O5N02Af2kTaEkv4Ktv2lzikxoysh c2yev0PXjfQeVvf/uRr0nyGopP7SsYtPAeanMerPM6L1MhDN+1R180Pf2P7evuCg7LhA nhVw== 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=n31vAJ0/z0WUmY2fan4e0nlYqV/i1KM7kpORiTJw8pE=; b=CpLfSDwbXlkf3vy8qAfAEHz/c6Ui/827nQRPxhsr2bhh/onZfbVbAuwp3JawoBfWcx JtpA1KcT3go7HC9XXNC3xA6oSFvD6Fr2ebI+ebzhDP2GXL46pfMBvTHYb1juGwdTARSA aCADTSqLQSpuT7iGEwNpBJ7iqaXX8Z2R8UIzjXUB0P+scc/YmQoj2wRUfwFSJVWOOKmR jlc7cxRfa/Ai0Bvv2K4+WMbkllA0aIbvhJRGm47col+cX7INs+XEr7nzI44a9if02MpG meUXsCeiRGyLBUDciw2E+trn9/r+Lb776gNQfBIQaEOd80jvJaJNr0RAFdy6ydTfzeHL 6J9Q== X-Gm-Message-State: AOAM5339MBmuGVQOrDEiclZ7+0GkQPu7SZNPPkFOuZdhDtiFaQ9V5qaG uyxd6UIGncsmtzqFEkF0ZKWCLgT8bWQaB0/3i8IU3ozxn5YYLw== X-Google-Smtp-Source: ABdhPJxpg3gVuE5mEUMDbXZTrOq2wPjFNWgqvK7rx5GUX7lQcmbT6aZDsF+bX2V/a64J8k56fyhG5p+fpEPtp9sRtDI= X-Received: by 2002:a2e:a49c:: with SMTP id h28mr6876319lji.417.1603735989094; Mon, 26 Oct 2020 11:13:09 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 26 Oct 2020 11:12:58 -0700 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="000000000000f1952205b296e1fe" Archived-At: Subject: [Webtransport] Call for agenda items: IETF 109 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, 26 Oct 2020 18:13:13 -0000 --000000000000f1952205b296e1fe Content-Type: text/plain; charset="UTF-8" WebTransport WG is scheduled to meet on Monday, November 16 at 16:00 - 18:00 UTC (9 AM - 11 AM Pacific). This is a call for agenda items for the upcoming meeting. A (very) early draft of the agenda is available here: https://datatracker.ietf.org/doc/agenda-109-webtrans/ --000000000000f1952205b296e1fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
WebTransport WG is scheduled to meet on M= onday, November 16 at 16:00 - 18:00 UTC (9 AM - 11 AM Pacific).=C2=A0
<= br>
This is a call for agenda items for the upcoming meeting.=C2= =A0

A (very) early draft of the agenda is availabl= e here:=C2=A0
--000000000000f1952205b296e1fe-- From nobody Tue Oct 27 09:22:30 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 D96963A10C0 for ; Tue, 27 Oct 2020 09:22:28 -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 lbsIfBdxKHHE for ; Tue, 27 Oct 2020 09:22:25 -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 7C9BB3A10C1 for ; Tue, 27 Oct 2020 09:22:20 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id 2so2386744ljj.13 for ; Tue, 27 Oct 2020 09:22:20 -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=dz2X6DLMuTu2L7wdq7JRVL139O15T4v+SW0kdtMXyUQ=; b=OHkoM5eP1CJ5kDzbITXAzAkqMVKDZjcD5Hxpm9vxz1b+hU8XoluWXeTliwda8iFzPf Mao2gF/CvmpKdSHOCYOG4h8SFIfLYNTwAtCYePd52VBz0+BijqAPxnckEYIHanrXYynM Hf4awtJahdPLGGlW6M9BxOt7CpcGYdO2P2SrF7OU12ySBFSO9nUw3ggHQebR32lrI0oP oobeoMZXdHGFA1cnz6kESImbAOOTjyFUAfb0b7iagnoOn52uHtGO+RHF0ht1MOlTatlu Oq48+ZJC98sBVrXoujmSitvNce0xB4bU7+9FGJZ9+nKRF0Awu3HGL5/TlJ5IqIEYBck3 /yMQ== 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=dz2X6DLMuTu2L7wdq7JRVL139O15T4v+SW0kdtMXyUQ=; b=BO8dfyWuWtbSEeE/htWcM+sk7YtX2wetX4742ydnxRvLYKoxvAOVwlrxi5JY0qSYS0 CsiA4Upg6+hrjr+pcVeY1UbogVVShoXBmIhqGSEu5jyzXmcpC4kSUkHVPK59xinuNXp9 6N0ULR6YWWdEJQ1IuIoiwueAxpHTUM7DcHUpLqBT1y4WOYwMI8Bty51eLeV5h7rzQ8aM jzMnc8ZQ9aED23gbOsaqpXEaaeinT8wL8xk/r8q7/yrmDVJX9cAKuLG2a6VwFnZqNcCM UhXRnF2L14ehehG/YcGPsCWofLnNBWg3LXKVtTlm5oRpHV1p83DX1d4IdqGNLEo3DrBa n+Xg== X-Gm-Message-State: AOAM533wB5OSeq1AkkYwK3mI48FkT+4yWx1aOU1pBnxLc79xaA/Q6Of2 XSXqA/cD2csSG9IT1prlGXMVAFlm7MC/dQUH+zW9xRiucuV2MQ== X-Google-Smtp-Source: ABdhPJwsFYGMI8wT1BlVxduL02YcYwjcRpeIAHHZkVZYxj+F/lJxJWatDAMngpJWUpQsj5GuSo9l4/zKWCMJMhjFEeY= X-Received: by 2002:a2e:8ed1:: with SMTP id e17mr1187783ljl.114.1603815737740; Tue, 27 Oct 2020 09:22:17 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Tue, 27 Oct 2020 12:22:06 -0400 Message-ID: To: WebTransport Content-Type: multipart/alternative; boundary="00000000000055af5505b2a97327" Archived-At: Subject: [Webtransport] Choosing the Transport, pt. 2 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, 27 Oct 2020 16:22:29 -0000 --00000000000055af5505b2a97327 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (previous iteration of this thread here ) Hello everyone, As you might remember, we've still not decided which of QuicTransport, Http2Transport and Http3Transport we should adapt: 1. There has been a strong interest in running WebTransport over HTTP. HTTP allows us to do connection pooling, a well-understood mechanism of falling back to TCP and better integration with existing load balancers. 2. There has also been interest in running WebTransport over QUIC itself, due to the complexity of WebTransport over HTTP, both in terms o= f design and in terms of writing servers for it (nice discussion here ). 3. There has been a desire to pick only one of those. I've been reworking the QuicTransport draft based on what we've found while implementing it in Chrome. Doing that, and observing how it becomes more and more like HTTP with every revision, has convinced me more than ever that all of the transports above should be the same thing conceptually, differing only in wire protocol. That observation was very helpful, since it allowed us to replace all of the different API entry points with just one, already dramatically simplifying the situation. Same observation also can potentially help us make some progress here. We can unify all of the proposals semantically (make them share a URL scheme and the headers format), and then the variants just become different encodings. If we compare the WebTransport proposals to the HTTP ecosystem, besides the obvious equivalences (webtransport-http2 =E2=89=85 HTTP/2, webtransport-htt= p3 =E2=89=85 HTTP/3), it becomes apparent that webtransport-quic =E2=89=85 HTTP/1.1. Th= is gives us a hint of why we might want all three of those. This is also really nice, since we know how to switch between all of those protocols, and we have a lot of experience with an ecosystem shaped like that: webtransport-quic and webtransport-http3 can be switched via ALPN, webtransport-http2 can be raced in parallel with the former. So I propose that we adapt all of them. As it stands, webtransport-quic is a simple-to-implement and proven-to-work solution that should not require much of working group's time. There are questions regarding whether webtransport-http is too complex; I believe that we won't know unless we try, and since there's clearly interest in trying, I believe we should adopt that draft and actually start working out those complex details. What does everyone think? Cheers, Victor. --00000000000055af5505b2a97327 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(previous iteration of this thread h= ere)

Hello everyone,

As you migh= t remember, we've still not decided which of QuicTransport, Http2Transp= ort and Http3Transport=C2=A0we should adapt:
  1. There has be= en a strong interest in running WebTransport over HTTP. HTTP allows us to d= o connection pooling, a well-understood mechanism of falling back to TCP an= d better integration with existing load balancers.
  2. There has also b= een interest in running WebTransport over QUIC itself, due to the complexit= y of WebTransport over HTTP, both in terms of design and in terms of writin= g servers for it (nice discussion here).
  3. There= has been a desire to pick only one of those.
I've been <= a href=3D"https://github.com/vasilvv/webtransport/pull/18">reworking=C2= =A0the QuicTransport draft based on what we've found while implementing= it in Chrome.=C2=A0 Doing that, and observing how it becomes more and more= like HTTP with every revision, has convinced me more than ever that all of= the transports above should be the same thing conceptually, differing only= in wire protocol.=C2=A0 That observation was very helpful, since it allowe= d us to replace<= /a> all of the different API entry points with just one, already dramatical= ly simplifying the situation.=C2=A0 Same observation also can potentially h= elp us make some progress here.=C2=A0 We can unify all of the proposals sem= antically (make them share a URL scheme and the headers format), and then t= he variants just become different encodings.

If we compare the WebTransport proposals to the HTTP ecosystem, besides th= e obvious equivalences (webtransport-http2=C2=A0=E2=89=85 HTTP/2, webtransp= ort-http3=C2=A0=E2=89=85 HTTP/3), it becomes apparent that webtransport-qui= c=C2=A0=E2=89=85 HTTP/1.1.=C2=A0 This gives us a hint of why we might want = all three of those.=C2=A0 This is also really nice, since we know how to sw= itch between all of those protocols, and we have a lot of experience with a= n ecosystem shaped like that: webtransport-quic and webtransport-http3 can = be switched via ALPN, webtransport-http2 can be raced in parallel with the = former.



--00000000000055af5505b2a97327-- From nobody Tue Oct 27 09:50:26 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 84D233A1172 for ; Tue, 27 Oct 2020 09:50:25 -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, RCVD_IN_DNSWL_BLOCKED=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 pUeaMsUAhlot for ; Tue, 27 Oct 2020 09:50:24 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 1EC9D3A116F for ; Tue, 27 Oct 2020 09:50:24 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id w27so3230212ejb.3 for ; Tue, 27 Oct 2020 09:50: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=bRKiPVxTRhd394l3vZemzWcteXyO+ADbIVTnFb6xt70=; b=ZyN1gEmnAlOxK3D81Qr2ipZbpKPoXsEbMxIOrwEpwRZq//4J5VhQJ9oIV9amDKBkyN OU0Hs/7NvVYVqdkXbAcZcuXD4tyoQqtUUKFffrIhrwATz+4l4qNL3/yH70clUiQndJqa JFWp50i+J4EXwwq6bDrFF327DDZWwNfE5GgsdGnBT2X6OlkOhOXye7TpbICgNJ7UswiZ yYyS2pwsTVu+VPw0t5R7fBJxpBFIxk4mFJcF2YLVt9ESjSxbZfm8PKkCzHuF+dfKveQF q/Yj288kuXEFV5VCZ73babSQgn620sHWyCU8HKQilEzJmrEo6wo6ccxpm2H9DmKI7Tp+ gNWg== 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=bRKiPVxTRhd394l3vZemzWcteXyO+ADbIVTnFb6xt70=; b=nH7g6BGfw2ugMb/9nFeSqamq3brLmCydhmGwes789SeSsW8X/qWb/Ve9ahPeDy4n2G oz5TEos7y4u00xvC9kKIjDdv22rPRi/hLYWiVPwSlxxmKxYIz44RIr5qWhEoUZsxiiIF iDxX4xydgPsJCCGdjFJf2rACMVWt6tV8aEdjxnsSNsUJhuJqiVS7CxvL0HqaypPnId4f cbu15U0/CQQjpATZJZK+bKT5w2x0RecwltrS5F/4jIZTlaIedncUoSMCy6WHMAlsaCcq U1rb/m1d3fnA+h/9UuipIWgcnH1qbC1LtpnusmMuz9nxSliFA/JyloMdHy66VXWU4dbz y9UQ== X-Gm-Message-State: AOAM530gWOtaDnMkYMoHJznUCRQpv+Wa+3skJtUX5MRKkDzb1u+Pekmw 77O19hEcCghRJc4tanp2b+kCVZkdF4tOKtVHoBq0+/IMf6k= X-Google-Smtp-Source: ABdhPJzCVRwJASMraFHbp3tZ2XqU3Z3GYyjoyHkkYW+o1t97e2YUumqQ5RDkGK3pWhPqVNFCOdgssjTlHCjkEAAPygU= X-Received: by 2002:a17:906:3b43:: with SMTP id h3mr3244470ejf.542.1603817422666; Tue, 27 Oct 2020 09:50:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lucas Pardue Date: Tue, 27 Oct 2020 16:50:14 +0000 Message-ID: To: Victor Vasiliev Cc: WebTransport Content-Type: multipart/alternative; boundary="000000000000c3400905b2a9d7a8" Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 27 Oct 2020 16:50:26 -0000 --000000000000c3400905b2a9d7a8 Content-Type: text/plain; charset="UTF-8" Hey Victor, Thanks for the update. I reviewed the QuicTransport changes in the PR you linked and the similarity to HTTP was striking, so it's good that you call this out. I wonder what Http3Transport looks like now. Have you done that update? For me, it would help to understand what the drafts look like in this new model before considering what is adoption worthy. Maybe its simple but my imagination is lacking right now. Cheers Lucas > --000000000000c3400905b2a9d7a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Victor,

= Thanks for the update. I reviewed the QuicTransport changes in the PR you l= inked and the similarity to HTTP was striking, so it's good that you ca= ll this out.

I wonder wh= at Http3Transport looks like now. Have you done that update?

For me, it would help to understand w= hat the drafts look like in this new model before considering what is adopt= ion worthy. Maybe its simple but my imagination is lacking right now.
=

Cheers
Lucas



--000000000000c3400905b2a9d7a8-- From nobody Tue Oct 27 17:35:24 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 C62033A09F2 for ; Tue, 27 Oct 2020 17:35: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 ITImh-J8a3eA for ; Tue, 27 Oct 2020 17:35:21 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 536F23A1034 for ; Tue, 27 Oct 2020 17:34:14 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id k27so3240781oij.11 for ; Tue, 27 Oct 2020 17:34:14 -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=iZ+vS0pDQ8TDiuewpD4Otc1nh0MdXXgquwn1B78bBfM=; b=Aaq96zIyvaeFN3Tn66aSBg1GaUgriD1iwLOJJsxEzlklw2QyaEGtdxihjuFXfFg1NG +l5uSHvlETj7unmKqDMDHyH/8ZiY43V3d1G5YhBZodwqCmDCdef8KnQiXVRAbCrDzP9r caIVhwaJeJez9yvTpbD/G/0f/fO9VitCOoIuU9hNT49jwxb+fvGnuB6dCz+lgWyxhBz4 vnnMUZ608U1KxcLt6DCryC5LbB5folnqkxIVfdeZihYNzsn5rQaaXEnUB4WxjmVgKQ67 0K4//kdljN2G7VpC09NDlvpZYVrwaa79oZGDxV1P+0cCRhnUE7gpbFTHj9sYmh4/75EO SmLg== 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=iZ+vS0pDQ8TDiuewpD4Otc1nh0MdXXgquwn1B78bBfM=; b=lBoRAClAcegGET+NI98j5/52GvB+1GALhRrM6QhaexPk5hhhTEzBRG1cg5pzhBY+mw FyI6puT2bwIPCqax8a9m1TeoNEk4QaDcEC4uousaTg5pPMy016klfEW7oSnZhsJRIuOv JrQs3YOk+aMAOe0qjf6xMvIokLMrb4qw2gf9x+PeIVRxfeWbtH4XHUaX5Uh61tLjTimn muEL1BYgN9gbSRzt04s2Rk/Zpz8lvR2vIpJDI5ApY6NnxEn0V2Gc92gdthlNFGaWb14q FmgVQUFXV7WQHyIKenxz5EywcluTz1sAc0Jc33D1FzcZgTVc3fdork3P8y13dKZk4AUS p05Q== X-Gm-Message-State: AOAM533WUEKvR8KiFBR8yuw9NRBwKpcU0ePfz44NvEWNdbzwLow2aucm HMsSVexA+fOyrOzOk+cG1qdKtG2WTMz3XtvFsJU= X-Google-Smtp-Source: ABdhPJyAuZTfngPusgHCAFGHOR0uBVKtMXuE6q45xsnfdQZ/B9lnsvTiMjFdIgj/+q28YzGlQCFYVGBdbWacWoVoxHM= X-Received: by 2002:aca:2b05:: with SMTP id i5mr3557248oik.57.1603845253585; Tue, 27 Oct 2020 17:34:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Luke Curley Date: Tue, 27 Oct 2020 17:34:04 -0700 Message-ID: To: Lucas Pardue Cc: Victor Vasiliev , WebTransport Content-Type: multipart/alternative; boundary="0000000000009d5ebc05b2b0529c" Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 28 Oct 2020 00:35:23 -0000 --0000000000009d5ebc05b2b0529c Content-Type: text/plain; charset="UTF-8" Yeah, I definitely agree that there's a grey area between QuicTransport and Http3Transport. The QuicTransport indication is similar to HTTP, while HttpTransport behaves like QUIC. But I think the decision to implement multiple protocols needs to be more objective. Every WebTransport variant should add functionality or provide backwards compatibility. Otherwise we'll be defining and implementing standards that serve no purpose. On Tue, Oct 27, 2020 at 9:50 AM Lucas Pardue wrote: > Hey Victor, > > Thanks for the update. I reviewed the QuicTransport changes in the PR you > linked and the similarity to HTTP was striking, so it's good that you call > this out. > > I wonder what Http3Transport looks like now. Have you done that update? > > For me, it would help to understand what the drafts look like in this new > model before considering what is adoption worthy. Maybe its simple but my > imagination is lacking right now. > > Cheers > Lucas > > > >> -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --0000000000009d5ebc05b2b0529c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I definitely agree that there's a grey area betw= een QuicTransport and Http3Transport. The QuicTransport indication is simil= ar to HTTP, while HttpTransport behaves like QUIC.

But I= think the decision to implement multiple protocols needs to be more object= ive. Every WebTransport variant should add functionality or provide backwar= ds compatibility. Otherwise we'll be defining=C2=A0and implementing sta= ndards that serve no purpose.

On Tue, Oct 27, 2020 at 9:50 AM Lucas Pa= rdue <lucaspardue.24.7@gma= il.com> wrote:
Hey Victor,

Thanks for the update. I reviewed the QuicTransport changes in the PR= you linked and the similarity to HTTP was striking, so it's good that = you call this out.

I won= der what Http3Transport looks like now. Have you done that update?

For me, it would help to underst= and what the drafts look like in this new model before considering what is = adoption worthy. Maybe its simple but my imagination is lacking right now.<= /div>

Cheers
Lucas



--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--0000000000009d5ebc05b2b0529c-- From nobody Tue Oct 27 22:40:57 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 187133A0EE2 for ; Tue, 27 Oct 2020 22:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 K6hycyTefGW5 for ; Tue, 27 Oct 2020 22:40:54 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400100.outbound.protection.outlook.com [40.107.140.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CE253A0EE1 for ; Tue, 27 Oct 2020 22:40:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ks1ofBl5vG3aoZGVeKrOVhlvtRJ6fPlsdQUt7LSU5qK/FlLJXimnL1UH8+sYc2L8RElBvqdg5kI0IkmOR+RKtqVVCNX/3h1a7lO43VAveRtgQMkB8A+TQpWyqyRjdzNKBRhKDv+AeMtL1Kw+S61J6oxNNliIIF8MqVYqgc/TjJWtTMHErrdZf2g/KUPXzUnr48N3sGbX+ncX1gA30N8Qu4RpuBOjiX7/HKs8WCNVrDZRonLusWKWtWH9in9sEEZyFmAtY3lSVtDc7qr5bTpXOc9azPangRk/HNwkcMh/xPKBtZ0+nZvcvZr3s8WU7zuc5aTlxipKhAzJrafokEEkkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8diRO750LKfauxklmvrxobnLFhAMkqw1Ddd0WE2uUME=; b=ZgwquDfvCggcOjJc5PSJ0fh8HYkX/3gfPdU+OFyi+NSphSDscZmgvi8E0qEEZgvlN1eR/z3De0J5dI93o2upW7NkAI/a5jijKQwLdBrFVPrzVSqdyBiRs/V3khEoSXpyfTceRVc7rIIhZfmiD0A6f1Ypn2xcK8tID3wSp4ML4ZbtnFoYF+cLSZPt5k+FrK22Ufo6w7qkgBCcxfbtDZOyx6Ji23NW/YqepOmT/oBZK9Z7ZLzhc5J2KKTZL7G4dktrJ1YmJ5pX3pA/9x3wu8YsuMC/yCaJzoVlrXtTk7WO5T5nORg+pfhBLVL20zvxFs0uqqFb+Clfs/rVYs1sct3aSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8diRO750LKfauxklmvrxobnLFhAMkqw1Ddd0WE2uUME=; b=ozLKKFKZMOfvW7Ic4UpLsy5WH9/MlTrBUW9MS27xImpLxwjH9SOPkCP91CawS+kIThZs+zPfv4IIAqBG5ZBkjN4Gx6jvnHblvuRtY4svRQkNYcbrT/60EfIZVDDbvCZmhoqKDco5TuVt3PTQmTnxYTVftUi7xDKYJ57cGOs32Tg= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSAPR01MB4146.jpnprd01.prod.outlook.com (2603:1096:604:57::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22; Wed, 28 Oct 2020 05:40:52 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7%6]) with mapi id 15.20.3477.028; Wed, 28 Oct 2020 05:40:51 +0000 To: Luke Curley , Lucas Pardue Cc: Victor Vasiliev , WebTransport References: From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <3ad5cc09-315b-ec3b-419d-807e5356b8a8@it.aoyama.ac.jp> Date: Wed, 28 Oct 2020 14:40:48 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [114.182.253.12] X-ClientProxiedBy: TYAPR03CA0001.apcprd03.prod.outlook.com (2603:1096:404:14::13) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (114.182.253.12) by TYAPR03CA0001.apcprd03.prod.outlook.com (2603:1096:404:14::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.4 via Frontend Transport; Wed, 28 Oct 2020 05:40:51 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5db8ba8d-8975-4617-53b4-08d87b0407fb X-MS-TrafficTypeDiagnostic: OSAPR01MB4146: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iKn1WtdppR6kQMJp6harSeeikLmBt04G9m32WZZWH98d79jzXCbxKTb6p3TZMlF4EBMcHnIaRm+makxXXatsjkGJayW253YN4xT/EOK+ZwlQW0R5lVSaJXxFzb56uCbrhCvbh9syyiRKHqO2ENQko3pC7Ck1iXdGNya9wtrKF+Uc8kgt74nVbFdZGIDC81ZsJoA4HWVC+QH039ahxx4IBqWP4K8E/Nf5JJmSi4FtH7A78PxAVwAkBdzmEJwcSqSiayurAdEelhD219bb4hBsFe8LhbtQwgz30dkhq0OUDV/S7Li/rBcB7bhpkdTqVuNOENDfoTil5EJ4NJ4kN058RNa4TeRg1JxKfE1+kXoknUdyvzPLWrIrXNXgaWWzGuod X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(39840400004)(136003)(396003)(66476007)(53546011)(54906003)(16576012)(26005)(52116002)(478600001)(16526019)(8676002)(6666004)(36916002)(66556008)(186003)(66946007)(8936002)(5660300002)(4744005)(31686004)(110136005)(4326008)(786003)(2906002)(316002)(6486002)(956004)(2616005)(86362001)(31696002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: SdvxttYY9QeHjSRqkAitNKAsqmlCz1rc+QVbMgsnNfBZ2otj5+E1zERtE81lOComGIfM8HKXjf/pCUPz3fh3cuhyadp5L+B1xgLDyehVp+2O8F9f5rRauqxwLO6FPSRGWD/WdLebmqnY1A9bSVzoacOOoeJPPxp6QUkDlTWlR+sN6h4raNuUKMjtQx4Q7Zm8DBAbAfrg45wf61HCFcDPoCG4Ts+cXB4PSMqQy8V+OzPJemx9cfcjCBLKXx3YHfg0WJ8Q+IAyFIeTPC+lH+1N6+QQdbvZt359rjYBtgHmA7JGFYfg06hwwv0C4DFn+4FtRWZXp+sYtCuKmnKwAiPc2xDbbYgYlWGsqAXxCvsAh+8xNq6TB6V0XDkn5veaLbKs1F4hw6VqudsQ79BL4Ap6SIqe37cruVO62ceEeycyxn1OVLOzWUFxWBmLgg6avSdDPjjbktA+QPtwXdoADXaGqgk+pB7KCyEM/RHp80wYKlwKmY+TfHvvSbUbNgATaCcWjZXMSyyBDFl7Y8yjbYorcQx2kq+yD08rK+eBHCwQa5vOU+/VV6T7Z6X94N41WSZkHjK9kcoFMI2+nTFOfkw8wvLlMHcCAlpBmUrQ9cJvI/jVUgDCJE4Hz0KjUoXW4k0A1gLDHANKPHOsNdOG0nICSg== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 5db8ba8d-8975-4617-53b4-08d87b0407fb X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2020 05:40:51.8841 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: v8UGf+YpJHimAfmVS+CLh6pW/hq0Nd0WAAwtIUhCiIROfDH3AnsAsRw135bQ36zd9M+ujQxsZEB2u00S7Ef/gQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB4146 Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 28 Oct 2020 05:40:56 -0000 On 28/10/2020 09:34, Luke Curley wrote: > Yeah, I definitely agree that there's a grey area between QuicTransport and > Http3Transport. The QuicTransport indication is similar to HTTP, while > HttpTransport behaves like QUIC. I'm confused by the last sentence. Reformatting it, it reads: The QuicTransport indication is similar to HTTP, while HttpTransport behaves like QUIC. Is that a typo, or does this crossover naming carry some deep philosophical meaning that I didn't get? Regards, Martin. > But I think the decision to implement multiple protocols needs to be more > objective. Every WebTransport variant should add functionality or provide > backwards compatibility. Otherwise we'll be defining and implementing > standards that serve no purpose. From nobody Wed Oct 28 01:58:57 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 D51763A0657 for ; Wed, 28 Oct 2020 01:58:55 -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 kSuPvuosCJ0N for ; Wed, 28 Oct 2020 01:58:54 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 0438F3A05A6 for ; Wed, 28 Oct 2020 01:58:53 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id s89so3620500ybi.12 for ; Wed, 28 Oct 2020 01:58:53 -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=V1El+iKBdypa4CvhTYLGFpEAez3W2UIzjWG1xCCmoSU=; b=uVHRBWaXRYU1Zb0YFj8Plp4mfES2n1Dic2R3KuEANJQZ/a68G5IkbZZlQUwRnU6/ph y7GDBZmFxuwS2XOJdLG92cDucOTbPHXqiP9MZ+Y2ZBOBV+d3HXFz7BGTx5U1Ss1T+XaV 509TXZSRXokYx44iE2+8xQvPysvQ1nuRrPvx3opArFe6mQzqsMxTVuuKrtXR/KsY+ZXT gkOW7kDk2ghjmuCKW077TObPrc/9GAwNitibUJZCX9qbG8HYF5USKAuaS3CgVv0gC7bQ U/W9QRYlxe1p9ZRsjfD5pXoZYzQWti2U9SRShsIxDhXGvf8usxDCodm8VEq6U/cpYxKI A4Uw== 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=V1El+iKBdypa4CvhTYLGFpEAez3W2UIzjWG1xCCmoSU=; b=a+JpfIg+4KFBz6OoFTLustB5hXYLUiuewmJNJ8SdwMK3x2F4yLD571ab/F+3tl1dJ1 hFBxUBheLedpPPiKavTfa0u8ay/ZQMjI5qCTUCRjoPW4J5DsbYmS0k3e3LxbYQ3SC6BR GOb8xL6+7TqoNXzv3gvvenouldLJFe++pBzkA1ettz95MrL1MuJABirsnoOIXVZl2Gcl r7l/KewDTIjJT5rYTWskR+sMFHnWOlniMRW8T/f+LPVTOffAiq4jyEJNhY+hxlhhaGqX ZyxS39Z751pittbTwiQVa8/JxfpgxmzbpF+ShtucvG2u98Q+ulM9kJOTQyzc+UoZac9s OEZw== X-Gm-Message-State: AOAM532yn6mkjlT5b1ry3UHu9BhUhFiRY9Yvxn/1Vi2xvSoN2/jKbg98 py6NHdiy/H01ZlPqAo5zEAx6rILznNEfh4Obys04WMK9+n3kCq2f X-Google-Smtp-Source: ABdhPJz7Fz3bu4ukiBE7tzI4/T2yU9fL72Plj9HexT6WrYZXt5A5hO2I5pUWu9yADH0ZMlx5y1wQyyW+nMIO9eMOmzE= X-Received: by 2002:a25:cc85:: with SMTP id l127mr8114051ybf.49.1603875532857; Wed, 28 Oct 2020 01:58:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: virat tara Date: Wed, 28 Oct 2020 14:28:40 +0530 Message-ID: To: Victor Vasiliev Cc: WebTransport Content-Type: multipart/alternative; boundary="0000000000006662f605b2b75f70" Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 28 Oct 2020 08:58:56 -0000 --0000000000006662f605b2b75f70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are the challenges in implementing WebTransport over HTTP related to the ones that are being faced while implementing RFC 8441 (WebSockets over HTTP)? I suspect this because RFC 8441 has been in development for a long time. On Tue, Oct 27, 2020 at 9:52 PM Victor Vasiliev wrote: > (previous iteration of this thread here > > ) > > Hello everyone, > > As you might remember, we've still not decided which of QuicTransport, > Http2Transport and Http3Transport we should adapt: > > 1. There has been a strong interest in running WebTransport over HTTP. > HTTP allows us to do connection pooling, a well-understood mechanism o= f > falling back to TCP and better integration with existing load balancer= s. > 2. There has also been interest in running WebTransport over QUIC > itself, due to the complexity of WebTransport over HTTP, both in terms= of > design and in terms of writing servers for it (nice discussion here > > ). > 3. There has been a desire to pick only one of those. > > I've been reworking the > QuicTransport draft based on what we've found while implementing it in > Chrome. Doing that, and observing how it becomes more and more like HTTP > with every revision, has convinced me more than ever that all of the > transports above should be the same thing conceptually, differing only in > wire protocol. That observation was very helpful, since it allowed us to > replace all of the > different API entry points with just one, already dramatically simplifyin= g > the situation. Same observation also can potentially help us make some > progress here. We can unify all of the proposals semantically (make them > share a URL scheme and the headers format), and then the variants just > become different encodings. > > If we compare the WebTransport proposals to the HTTP ecosystem, besides > the obvious equivalences (webtransport-http2 =E2=89=85 HTTP/2, webtranspo= rt-http3 =E2=89=85 > HTTP/3), it becomes apparent that webtransport-quic =E2=89=85 HTTP/1.1. = This gives > us a hint of why we might want all three of those. This is also really > nice, since we know how to switch between all of those protocols, and we > have a lot of experience with an ecosystem shaped like that: > webtransport-quic and webtransport-http3 can be switched via ALPN, > webtransport-http2 can be raced in parallel with the former. > > So I propose that we adapt all of them. As it stands, webtransport-quic > is a simple-to-implement and proven-to-work solution that should not > require much of working group's time. There are questions regarding > whether webtransport-http is too complex; I believe that we won't know > unless we try, and since there's clearly interest in trying, I believe we > should adopt that draft and actually start working out those complex > details. > > What does everyone think? > > Cheers, > Victor. > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --0000000000006662f605b2b75f70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are the challenges in implementing WebTransport over = HTTP related to the ones that are being faced while implementing RFC 8441 (WebSockets over HTTP)? = I suspect this because RFC 8441 has been in development for a long time.

On Tue, Oct 27, 2020 at 9:52 PM Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wro= te:
(previous iteration of this thread here)

Hello everyone,

As yo= u might remember, we've still not decided which of QuicTransport, Http2= Transport and Http3Transport=C2=A0we should adapt:
  1. There = has been a strong interest in running WebTransport over HTTP. HTTP allows u= s to do connection pooling, a well-understood mechanism of falling back to = TCP and better integration with existing load balancers.
  2. There has = also been interest in running WebTransport over QUIC itself, due to the com= plexity of WebTransport over HTTP, both in terms of design and in terms of = writing servers for it (nice discussion = here).
  3. There has been a desire to pick only one of those.
    4. <= /ol>
    I've been reworking=C2=A0the QuicTransport draft based = on what we've found while implementing it in Chrome.=C2=A0 Doing that, = and observing how it becomes more and more like HTTP with every revision, h= as convinced me more than ever that all of the transports above should be t= he same thing conceptually, differing only in wire protocol.=C2=A0 That obs= ervation was very helpful, since it allowed us to replace all of the = different API entry points with just one, already dramatically simplifying = the situation.=C2=A0 Same observation also can potentially help us make som= e progress here.=C2=A0 We can unify all of the proposals semantically (make= them share a URL scheme and the headers format), and then the variants jus= t become different encodings.

If we compare = the WebTransport proposals to the HTTP ecosystem, besides the obvious equiv= alences (webtransport-http2=C2=A0=E2=89=85 HTTP/2, webtransport-http3=C2=A0= =E2=89=85 HTTP/3), it becomes apparent that webtransport-quic=C2=A0=E2=89= =85 HTTP/1.1.=C2=A0 This gives us a hint of why we might want all three of = those.=C2=A0 This is also really nice, since we know how to switch between = all of those protocols, and we have a lot of experience with an ecosystem s= haped like that: webtransport-quic and webtransport-http3 can be switched v= ia ALPN, webtransport-http2 can be raced in parallel with the former.
=

So I propose that we adapt all of them.=C2=A0 As it sta= nds, webtransport-quic is a simple-to-implement and proven-to-work solution= that should not require much of working group's time.=C2=A0 There are = questions regarding whether webtransport-http=C2=A0is too complex; I believ= e that we won't know unless we try, and since there's clearly inter= est in trying, I believe we should adopt that draft and actually start work= ing out those complex details.

What does everyone = think?

Cheers,
=C2=A0 Victor.
=
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--0000000000006662f605b2b75f70-- From nobody Wed Oct 28 02:03:24 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 CD6833A05A6 for ; Wed, 28 Oct 2020 02:03:23 -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=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 JzMTmWX8K7cv for ; Wed, 28 Oct 2020 02:03:21 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 36ACE3A0475 for ; Wed, 28 Oct 2020 02:03:21 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id o14so3603113otj.6 for ; Wed, 28 Oct 2020 02:03:21 -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=6YSkJ0eVyh10okGXZnVnNna9g8Q/Pv6tM4J0RBDgyto=; b=E4M++XakAKaTiLPoRczQjFi6i0DRS1mP7c4fsYDFEPQr+j+1CtugG+0Ui2vRAoFJgi y+ZSiYrNlDequu7XMGuO9qvHKrY4KSRk0upuRwNhFlnXKIHerIS8cBz6QgrY6MCtcd9g PV5agbyeq6hXXbFDkFqdCHTa9tGnwgQAKOQ78X2y+farZf5yknyjt8YqnHmte9LBiCuX kK1HjYMysgD2QfK1OlOzYiryIzkIkMXov4gvQv6xaspjXZtD1BjNGcw97+N6XWJjr4MN ZSbRP2EDnnOaKxWmtY5Je03pu1qplCT2o5VdkGolrfAQ+VKuxdqEB9+7ijq+qA4tZOEh jQdw== 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=6YSkJ0eVyh10okGXZnVnNna9g8Q/Pv6tM4J0RBDgyto=; b=DdAL7hKHtV6jNtTnRav3wM51pcvMmHgsV62UHsCBQvyAn3FB99f0+ZMMBP7wWiJUpc jsSXhtsLhxVaMkOVSgM8OvQjAhJcqiC2X0qDuJOjMPT1DkAd/bdczjuTF1S8L0iTQDug 85x5nTstdsK71sGiT6vrDiXEF//bSYRfy5yU8WgbXuMdEnM58ZONVeLVsjUzcONXm1bM kh1RH172j7SQP/WSsv3fGbVxoaNngu3E8lvw9T5L8UpTsXpIEXG9ZIUlu+c1B5jhbfTf Us8AwgtEnxzLKg2Wj9aqn1895cjwFMb/soYAtrr5phUA5pEplH9k6WDIae2E71VtsrSi Z/CA== X-Gm-Message-State: AOAM532y5uCPG/wwIRz3Bv6ygbIYFZ5kQ0YnO/oBbQTJI3dcuJl1hDz0 IPfWkgp5zSvvIUGxsfnqcQCx4hfWz273A+vGpMk= X-Google-Smtp-Source: ABdhPJwdbju547YDuZ7vPpB+imD8OLy5EWTRQDUa4OoDxVRdIShGBhicLHJQScQn5OL5oxF0oxURCTplwbGnqoiasOU= X-Received: by 2002:a05:6830:4033:: with SMTP id i19mr4643440ots.127.1603875799947; Wed, 28 Oct 2020 02:03:19 -0700 (PDT) MIME-Version: 1.0 References: <3ad5cc09-315b-ec3b-419d-807e5356b8a8@it.aoyama.ac.jp> In-Reply-To: <3ad5cc09-315b-ec3b-419d-807e5356b8a8@it.aoyama.ac.jp> From: Luke Curley Date: Wed, 28 Oct 2020 02:03:09 -0700 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: Lucas Pardue , Victor Vasiliev , WebTransport Content-Type: multipart/alternative; boundary="00000000000051e1c205b2b76f54" Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 28 Oct 2020 09:03:24 -0000 --00000000000051e1c205b2b76f54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, I was trying to be too terse and should explain. The QuicTransport indication involves an origin and a path using a custom encoding. Like Victor mentioned, these are very similar to existing HTTP headers and could be encoded as such. This would reduce the differences between QuicTransport and Http3Transport. Http3Transport establishes the connection with HTTP headers but then ditches the HTTP semantics. It instead exposes the underlying QUIC connection and offers the same API as QUIC and QuicTransport. I was trying to express that QuicTransport and Http3Transport are converging. You can look at this in one of two ways: Either there's not enough differences to justify two protocols, or there are so few differences that they can share everything but the wire protocol. On Tue, Oct 27, 2020 at 10:40 PM Martin J. D=C3=BCrst wrote: > On 28/10/2020 09:34, Luke Curley wrote: > > Yeah, I definitely agree that there's a grey area between QuicTransport > and > > Http3Transport. The QuicTransport indication is similar to HTTP, while > > HttpTransport behaves like QUIC. > > I'm confused by the last sentence. Reformatting it, it reads: > > The QuicTransport indication is similar to HTTP, > while HttpTransport behaves like QUIC. > > Is that a typo, or does this crossover naming carry some deep > philosophical meaning that I didn't get? > > Regards, Martin. > > > But I think the decision to implement multiple protocols needs to be mo= re > > objective. Every WebTransport variant should add functionality or provi= de > > backwards compatibility. Otherwise we'll be defining and implementing > > standards that serve no purpose. > > --00000000000051e1c205b2b76f54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, I was trying to be too terse and should explai= n.

The QuicTransport indication involves an origin= and a path using a custom encoding. Like Victor mentioned, these are very = similar to existing HTTP headers and could be encoded as such. This would r= educe the differences between QuicTransport and Http3Transport.
<= br>
Http3Transport establishes the connection with=C2=A0HTTP head= ers but then ditches the HTTP semantics. It instead exposes the underlying = QUIC connection and offers the same API as QUIC and QuicTransport.

I was=C2=A0trying to express that QuicTransport and Http3T= ransport are converging. You can look at this in one of two ways: Either th= ere's not enough differences to justify two protocols, or there are so = few differences that they can share everything but the wire protocol.
=

= On Tue, Oct 27, 2020 at 10:40 PM Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:
On 28/10/2020 09:34, Luke Cu= rley wrote:
> Yeah, I definitely agree that there's a grey area between QuicTran= sport and
> Http3Transport. The QuicTransport indication is similar to HTTP, while=
> HttpTransport behaves like QUIC.

I'm confused by the last sentence. Reformatting it, it reads:

The=C2=A0 =C2=A0QuicTransport indication is similar to HTTP,
while HttpTransport behaves=C2=A0 =C2=A0 =C2=A0 =C2=A0like=C2=A0 =C2=A0 =C2= =A0 =C2=A0QUIC.

Is that a typo, or does this crossover naming carry some deep
philosophical meaning that I didn't get?

Regards,=C2=A0 =C2=A0Martin.

> But I think the decision to implement multiple protocols needs to be m= ore
> objective. Every WebTransport variant should add functionality or prov= ide
> backwards compatibility. Otherwise we'll be defining and implement= ing
> standards that serve no purpose.

--00000000000051e1c205b2b76f54-- From nobody Wed Oct 28 11:43: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 58E383A0B1C for ; Wed, 28 Oct 2020 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=apple.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 soJsLLHt23k8 for ; Wed, 28 Oct 2020 11:42:51 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2803A0B01 for ; Wed, 28 Oct 2020 11:42:51 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 09SIVUYd051395; Wed, 28 Oct 2020 11:42:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=LPkUbMaeCIjkzyCRKuIzirFqcDcWKGANxhhTTkhVG6o=; b=v2vple+c7JYwCFVKC8USRhEfJJNmv5WAHMLS0Y9wIMRkfhfbljr/LVDEHKTD4vo65mId vPkINEaKAvrimTc8OtVmTl/P2kHvs97f+cMupL07NAnjzF0TNuQjITJnEAk2ncaN+p7p pzhhFQjyPXvfDeIVMXkYrgE9YgX/jixG4TRxA2sEpc5dk8EHOLXBj9CqL8t5NddVN2uh A86zh3lZnSuMqeJJ2DLvYKQ7eo09Z+ReJtjSFdJNgnrn2CF+6SdyuvSeq3Zx4L08Mihf 6RMdUsiIAaI16aEtLnbQVH9FDt3a/2JK9W2mrKBEJZC8Gh1++h0Xn5pVK/HY/3VPLAmV 0w== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp01.apple.com with ESMTP id 34ck70h52n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Oct 2020 11:42:49 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QIX00QZ4DBDK850@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 28 Oct 2020 11:42:49 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QIX00L00CSLMC00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 28 Oct 2020 11:42:49 -0700 (PDT) X-Va-A: X-Va-T-CD: 8e2e2c6928f764e550980fed99e76b0a X-Va-E-CD: ba8e5c4021b421984355f88a3496abda X-Va-R-CD: 2062095a3df3f4291d25fd6bd9302cd2 X-Va-CD: 0 X-Va-ID: c49cfcb2-ad0e-43d9-9574-27dfd1db60e8 X-V-A: X-V-T-CD: 8e2e2c6928f764e550980fed99e76b0a X-V-E-CD: ba8e5c4021b421984355f88a3496abda X-V-R-CD: 2062095a3df3f4291d25fd6bd9302cd2 X-V-CD: 0 X-V-ID: e1f3f3cf-018e-4dab-924e-3f42380cb013 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-28_09:2020-10-28, 2020-10-28 signatures=0 Received: from [17.234.61.37] (unknown [17.234.61.37]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QIX00SEWDBCN400@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 28 Oct 2020 11:42:49 -0700 (PDT) From: Eric Kinnear Message-id: <8854F1BE-31ED-4C06-9D43-D9EABE686F0B@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_16DFDD44-ECE7-46F6-AD2E-BB4600526E61" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 28 Oct 2020 11:42:48 -0700 In-reply-to: Cc: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Victor Vasiliev , WebTransport , Lucas Pardue To: Luke Curley References: <3ad5cc09-315b-ec3b-419d-807e5356b8a8@it.aoyama.ac.jp> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-28_09:2020-10-28, 2020-10-28 signatures=0 Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 28 Oct 2020 18:43:00 -0000 --Apple-Mail=_16DFDD44-ECE7-46F6-AD2E-BB4600526E61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 28, 2020, at 2:03 AM, Luke Curley wrote: >=20 > Sorry, I was trying to be too terse and should explain. >=20 > The QuicTransport indication involves an origin and a path using a = custom encoding. Like Victor mentioned, these are very similar to = existing HTTP headers and could be encoded as such. This would reduce = the differences between QuicTransport and Http3Transport. >=20 > Http3Transport establishes the connection with HTTP headers but then = ditches the HTTP semantics. It instead exposes the underlying QUIC = connection and offers the same API as QUIC and QuicTransport. >=20 > I was trying to express that QuicTransport and Http3Transport are = converging. You can look at this in one of two ways: Either there's not = enough differences to justify two protocols, or there are so few = differences that they can share everything but the wire protocol. Just curious: if they share everything but the wire protocol, then are = there significant use cases where we=E2=80=99d expect someone to need or = only support one wire protocol over another? In other words, if they = share everything but a wire protocol, why do we need two wire protocols?=20= (There may be completely sensible reasons for this, just thought I=E2=80=99= d ask since I thought we=E2=80=99d previously been discussing choosing = one or the other as a layering decision, rather than maintaining both.) Thanks, Eric >=20 > On Tue, Oct 27, 2020 at 10:40 PM Martin J. D=C3=BCrst = > wrote: > On 28/10/2020 09:34, Luke Curley wrote: > > Yeah, I definitely agree that there's a grey area between = QuicTransport and > > Http3Transport. The QuicTransport indication is similar to HTTP, = while > > HttpTransport behaves like QUIC. >=20 > I'm confused by the last sentence. Reformatting it, it reads: >=20 > The QuicTransport indication is similar to HTTP, > while HttpTransport behaves like QUIC. >=20 > Is that a typo, or does this crossover naming carry some deep=20 > philosophical meaning that I didn't get? >=20 > Regards, Martin. >=20 > > But I think the decision to implement multiple protocols needs to be = more > > objective. Every WebTransport variant should add functionality or = provide > > backwards compatibility. Otherwise we'll be defining and = implementing > > standards that serve no purpose. >=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport --Apple-Mail=_16DFDD44-ECE7-46F6-AD2E-BB4600526E61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 28, 2020, at 2:03 AM, Luke Curley <kixelated@gmail.com>= wrote:

Sorry, I was trying to be too = terse and should explain.

The QuicTransport indication involves an origin and a path = using a custom encoding. Like Victor mentioned, these are very similar = to existing HTTP headers and could be encoded as such. This would reduce = the differences between QuicTransport and Http3Transport.

Http3Transport = establishes the connection with HTTP headers but then ditches the = HTTP semantics. It instead exposes the underlying QUIC connection and = offers the same API as QUIC and QuicTransport.

I was trying to express that = QuicTransport and Http3Transport are converging. You can look at this in = one of two ways: Either there's not enough differences to justify two = protocols, or there are so few differences that they can share = everything but the wire protocol.

Just curious: if they share everything but the wire = protocol, then are there significant use cases where we=E2=80=99d expect = someone to need or only support one wire protocol over another? In other = words, if they share everything but a wire protocol, why do we need two = wire protocols? 
(There may be completely sensible = reasons for this, just thought I=E2=80=99d ask since I thought we=E2=80=99= d previously been discussing choosing one or the other as a layering = decision, rather than maintaining both.)

Thanks,
Eric


On Tue, Oct 27, 2020 at 10:40 PM Martin J. D=C3=BCrst= <duerst@it.aoyama.ac.jp> wrote:
On 28/10/2020 09:34, Luke Curley = wrote:
> Yeah, I definitely agree that there's a grey area between = QuicTransport and
> Http3Transport. The QuicTransport indication is similar to HTTP, = while
> HttpTransport behaves like QUIC.

I'm confused by the last sentence. Reformatting it, it reads:

The   QuicTransport indication is similar to HTTP,
while HttpTransport behaves       like    =    QUIC.

Is that a typo, or does this crossover naming carry some deep
philosophical meaning that I didn't get?

Regards,   Martin.

> But I think the decision to implement multiple protocols needs to = be more
> objective. Every WebTransport variant should add functionality or = provide
> backwards compatibility. Otherwise we'll be defining and = implementing
> standards that serve no purpose.

--
Webtransport mailing list
Webtransport@ietf.org
https://www.ietf.org/mailman/listinfo/webtransport

= --Apple-Mail=_16DFDD44-ECE7-46F6-AD2E-BB4600526E61-- From nobody Thu Oct 29 04:17: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 2575A3A0B5C for ; Thu, 29 Oct 2020 04:17:37 -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 2c1M_lWoZdwI for ; Thu, 29 Oct 2020 04:17:34 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 A53D43A0AE3 for ; Thu, 29 Oct 2020 04:17:33 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id y184so810492lfa.12 for ; Thu, 29 Oct 2020 04:17:33 -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=9vBogm4CxxzZ2ExmwolDhqSfxVspv4myfazIlOobBME=; b=TQpCGAkfcfNEj236TkzWmYoRseCAhdvpuhLZtxxDUOfjZVNMUojtZWcWtvdaP8btao 4TwU/CQpfcDtVXr5toeFSxR8P+YmWPJ22Hb1xlnGO3mNcII542nNU6fs91D+q4UEBs4v A9jEhPdAVf0QML6/wKdwZGjnWzZyfiD85eQUO1pLWyEy6f/ioGkFBvIa+htxkphpU0Ff 4popgY5GMQpW+npovgdKpw0BT3+8kuaDA+LKdCQYuP26mDuJhdpmSB8zt15Py8DR01F2 g0tsftB8LGpo7Aq3MM8VgTAddR0cFrKeNV9LByFu6dG/tB3zVwQ1TUkAgOKgn9FFsZNv gtGA== 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=9vBogm4CxxzZ2ExmwolDhqSfxVspv4myfazIlOobBME=; b=DveYjpor0hqGb9cMJBNNhdftS2tdheJUNkQGbnnh/jPH1tqNOKCxeUm+yFZ6JTFII2 70O7JRbtHtgIh1YnulF+hLZt9hwGie8KkKy6u9YZcb2258HCtuJ0gixjeSV9J2J0qZRz ePLJ+ejMv6LEKWoLgr+dIoC3jclpVDzSmCM/sJYj7oVFW6QkCla6zuW6s05zgvku5H3H yLEtLXECMd6qnJpkyDuvNYAW8mWPEguOu2vwX6o82pZdoznqazU4oJfy0M3jVboolE+L dtGL4rdVbq37tVNwo66m7UWtz4k/atRHPj6zNVbFZirNNnoC6wBzSeKMafL9mItG9gKq cS7Q== X-Gm-Message-State: AOAM53165ZZzQizEfgt2dsumqj1Ca4KyTje8Zhrks4EzOw3Gct8cYZ6w 6tLxhHJrBLdNadgHTxYIgdmcQSzY+hVYo0Ocj4/8yw== X-Google-Smtp-Source: ABdhPJzeUu6lQYP2fn1lr707liQWLidrT22kENjH0WX/1Bt23qO4UmE5h03esw0EXtHDef7Ab32Mn4xLY6QeuM94ctI= X-Received: by 2002:a05:6512:32b8:: with SMTP id q24mr1331704lfe.176.1603970251675; Thu, 29 Oct 2020 04:17:31 -0700 (PDT) MIME-Version: 1.0 References: <3ad5cc09-315b-ec3b-419d-807e5356b8a8@it.aoyama.ac.jp> <8854F1BE-31ED-4C06-9D43-D9EABE686F0B@apple.com> In-Reply-To: <8854F1BE-31ED-4C06-9D43-D9EABE686F0B@apple.com> From: Yutaka Hirano Date: Thu, 29 Oct 2020 20:17:18 +0900 Message-ID: To: Eric Kinnear Cc: Luke Curley , WebTransport , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Victor Vasiliev , Lucas Pardue Content-Type: multipart/alternative; boundary="00000000000015463f05b2cd6d31" Archived-At: Subject: Re: [Webtransport] Choosing the Transport, pt. 2 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, 29 Oct 2020 11:17:37 -0000 --00000000000015463f05b2cd6d31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to Victor. The server implementation cost is convincing to me. On Thu, Oct 29, 2020 at 3:43 AM Eric Kinnear wrote: > > > On Oct 28, 2020, at 2:03 AM, Luke Curley wrote: > > Sorry, I was trying to be too terse and should explain. > > The QuicTransport indication involves an origin and a path using a custom > encoding. Like Victor mentioned, these are very similar to existing HTTP > headers and could be encoded as such. This would reduce the differences > between QuicTransport and Http3Transport. > > Http3Transport establishes the connection with HTTP headers but then > ditches the HTTP semantics. It instead exposes the underlying QUIC > connection and offers the same API as QUIC and QuicTransport. > > I was trying to express that QuicTransport and Http3Transport are > converging. You can look at this in one of two ways: Either there's not > enough differences to justify two protocols, or there are so few > differences that they can share everything but the wire protocol. > > > Just curious: if they share everything but the wire protocol, then are > there significant use cases where we=E2=80=99d expect someone to need or = only > support one wire protocol over another? In other words, if they share > everything but a wire protocol, why do we need two wire protocols? > (There may be completely sensible reasons for this, just thought I=E2=80= =99d ask > since I thought we=E2=80=99d previously been discussing choosing one or t= he other > as a layering decision, rather than maintaining both.) > > Thanks, > Eric > > > On Tue, Oct 27, 2020 at 10:40 PM Martin J. D=C3=BCrst > wrote: > >> On 28/10/2020 09:34, Luke Curley wrote: >> > Yeah, I definitely agree that there's a grey area between QuicTranspor= t >> and >> > Http3Transport. The QuicTransport indication is similar to HTTP, while >> > HttpTransport behaves like QUIC. >> >> I'm confused by the last sentence. Reformatting it, it reads: >> >> The QuicTransport indication is similar to HTTP, >> while HttpTransport behaves like QUIC. >> >> Is that a typo, or does this crossover naming carry some deep >> philosophical meaning that I didn't get? >> >> Regards, Martin. >> >> > But I think the decision to implement multiple protocols needs to be >> more >> > objective. Every WebTransport variant should add functionality or >> provide >> > backwards compatibility. Otherwise we'll be defining and implementing >> > standards that serve no purpose. >> >> -- > 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 > --00000000000015463f05b2cd6d31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to Victor. The server implementation cost is convincing to= me.

On Thu, Oct 29, 2020 at 3:43 AM Eric Kinnear <ekinnear= =3D40apple.com@dmarc.ietf.org= > wrote:
=


On Oct 28, 2020, at 2:03 AM, Luke Curley <kixelated@gmail.com> wrote:
Sorry, I was trying to be too terse and s= hould explain.

The QuicTransport indication involv= es an origin and a path using a custom encoding. Like Victor mentioned, the= se are very similar to existing HTTP headers and could be encoded as such. = This would reduce the differences between QuicTransport and Http3Transport.=

Http3Transport establishes the connection with=C2= =A0HTTP headers but then ditches the HTTP semantics. It instead exposes the= underlying QUIC connection and offers the same API as QUIC and QuicTranspo= rt.

I was=C2=A0trying to express that QuicTranspor= t and Http3Transport are converging. You can look at this in one of two way= s: Either there's not enough differences to justify two protocols, or t= here are so few differences that they can share everything but the wire pro= tocol.

Just curious: if they s= hare everything but the wire protocol, then are there significant use cases= where we=E2=80=99d expect someone to need or only support one wire protoco= l over another? In other words, if they share everything but a wire protoco= l, why do we need two wire protocols?=C2=A0
(There may be complet= ely sensible reasons for this, just thought I=E2=80=99d ask since I thought= we=E2=80=99d previously been discussing choosing one or the other as a lay= ering decision, rather than maintaining both.)

Tha= nks,
Eric


On Tue, Oct 27, = 2020 at 10:40 PM Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 28/10/2020 09:34, Luke = Curley wrote:
> Yeah, I definitely agree that there's a grey area between QuicTran= sport and
> Http3Transport. The QuicTransport indication is similar to HTTP, while=
> HttpTransport behaves like QUIC.

I'm confused by the last sentence. Reformatting it, it reads:

The=C2=A0 =C2=A0QuicTransport indication is similar to HTTP,
while HttpTransport behaves=C2=A0 =C2=A0 =C2=A0 =C2=A0like=C2=A0 =C2=A0 =C2= =A0 =C2=A0QUIC.

Is that a typo, or does this crossover naming carry some deep
philosophical meaning that I didn't get?

Regards,=C2=A0 =C2=A0Martin.

> But I think the decision to implement multiple protocols needs to be m= ore
> objective. Every WebTransport variant should add functionality or prov= ide
> backwards compatibility. Otherwise we'll be defining and implement= ing
> standards that serve no purpose.

--
Webtransport mailing list
Webtransport@ietf.org
https://www.ietf.org= /mailman/listinfo/webtransport

--=
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--00000000000015463f05b2cd6d31--