From nobody Wed May 13 18:43:08 2020 Return-Path: X-Original-To: v3@ietfa.amsl.com Delivered-To: v3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FED63A0771 for ; Wed, 13 May 2020 18:43:06 -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 qL59JKt8h9Mn for ; Wed, 13 May 2020 18:43:05 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450: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 D494B3A0783 for ; Wed, 13 May 2020 18:43:04 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id g1so1679929ljk.7 for ; Wed, 13 May 2020 18:43:04 -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=WQUsHYiiXrnfK23I0Y7l/NoOQThW7f77fSR197iRp6U=; b=KYdd8cCMbSaeEOMPny0/rC3NounZGHl2MPHnK1cJLbhKev58eoUxRW7n14twvilvnL dIFmieeLsRNjJQb0hEKuEDFSubm50lXNN6OvXz8ALqW5nWUl6+NqLJJ41MYJblIauN8O qIBkjpMwPgFplJoSOLJ/5pahzx2jXx1Narruo2RSZF9nrujNS7qS976szMqS47hqR8E3 U7NqHc9I18q/0OXTCjuutQmGF6XQbFahiwkd/Fjq7McymAiRL2de7jeTbKwGyzSxNnwO 6ER3IV+67x5kemP80lrmZgOXB1tliKn7s9tpPmJtb7po0MCrSFeBX/bwt0vCr592xOGR DemQ== 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=WQUsHYiiXrnfK23I0Y7l/NoOQThW7f77fSR197iRp6U=; b=ExD51VqLjT/oZsvA/L6qi94HLqT/v/yIKseAYEvUUI9QM/aia4uCB3Fent8K1QNYVP P7Uggzshn+ZRq5pV5GrZN3WpuASTsot7xtB7njBvnY/jQrlGJNFwZpY7RX6jJdpubjy6 Zu4yhTT/Raw0YiNqFihXaghMLuMp0HbvnkAsUgKMx6TwhekehIMU1ISJgNKQdxR1uGtx wDLKVaXbkYRIEqm0vAkxQUEeR1GsQ6IrCNl2q13Npzfp4Hk2Qga8mHnpl4odijAZG2EU KBLKKm6dnz6D4c8nCSokQmOL3oBXhuxlp82+8VUkCqf8iV+tLBNcpnwnt47z652jLl44 he+Q== X-Gm-Message-State: AOAM533x4rKBYQ14QMR2omXXJ7j7MY8DS6RJRh++Swejg60kLWVMy91g tcFb9oQNYn+f/XbfRa69W7Oyqhl2nBJyW7U8H4svIGAwcSo= X-Google-Smtp-Source: ABdhPJw7x8Hhl6t2I9YqX9FzkG8a38biqGp3OEJQOVmzkXzSdXp4TSUGPEaBdQ8Nb8dFC1SFuNpVoDNqreu11okiU8w= X-Received: by 2002:a2e:8689:: with SMTP id l9mr1140113lji.193.1589420582704; Wed, 13 May 2020 18:43:02 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Wed, 13 May 2020 18:42:51 -0700 Message-ID: To: v3@ietf.org Content-Type: multipart/alternative; boundary="0000000000003b1c8a05a591d1de" Archived-At: Subject: [V3] RIPT Use Cases X-BeenThere: v3@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, 14 May 2020 01:43:07 -0000 --0000000000003b1c8a05a591d1de Content-Type: text/plain; charset="UTF-8" The W3C is currently looking at the use cases discussed in the IETF WEBTRANS and RIPT BOFs, in an effort to develop a W3C WebTransport charter, as well as to understand what other work might need to be done on the W3C side. Overall, the goal discussed in the RIPT BOF of "making it as easy to bring up a cloud-based RTC service as it is to bring up a Web service" seems to be resonating. However, the question has arisen as to whether WebTransport API and protocols as currently proposed satisfy all the needs discussed in the RIPT BOF. Initial discussions seem to indicate that there are potential use cases described in the RIPT BOF that go beyond the functionality proposed in the WebTransport protocols. In particular: 1. The goal of "leveraging Web-based cloud infrastructure" was not achieved by WebSockets, in part because of operational issues such as difficulties in leveraging CDNs and operational issues such as load balancing and draining of existing connections from endpoints that need to be removed from service. So the question is whether WebTransport will inevitably inherit some of those problems, even if it does support unreliable/unordered transport. 2. Slides in the RIPT BOF showed an HTTP/3 GET being responded to with HTTP/3 datagrams. This is not something that is contemplated in WebTransport (or is currently in discussion in HTTPBIS, as far as I am aware). But it does seem appealing for use cases such as a "moderate latency" streaming service that attempts to reduce video stalls by sending "discardable" frames using QUIC datagrams. --0000000000003b1c8a05a591d1de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The W3C is currently looking at the use cases discussed in= the IETF WEBTRANS and RIPT BOFs, in an effort to develop a W3C WebTranspor= t charter, as well as to understand what other work might need to be done o= n the W3C side.

Overall, the goal discussed in the RIPT = BOF of "making it as easy to bring up a cloud-based RTC service as it = is to bring up a Web service" seems to be resonating.=C2=A0 However, t= he question has arisen as to whether WebTransport API and protocols as curr= ently proposed satisfy all the needs discussed in the RIPT BOF.=C2=A0
=

Initial discussions seem to indicate that there are pot= ential use cases described in the RIPT BOF that go beyond the functionality= proposed in the WebTransport protocols. In particular:=C2=A0
1. The goal of "leveraging Web-based cloud infrastructure&= quot; was not achieved by WebSockets, in part because of operational issues= such as difficulties in leveraging CDNs and operational issues such as loa= d balancing and draining of existing connections from endpoints that need t= o be removed from service.=C2=A0 So the question is whether WebTransport wi= ll inevitably inherit some of those problems, even if it does support unrel= iable/unordered transport.=C2=A0

2. Slides in the = RIPT BOF showed an HTTP/3 GET being responded to with HTTP/3 datagrams. Thi= s is not something that is contemplated in WebTransport (or is currently in= discussion in HTTPBIS, as far as I am aware).=C2=A0 But it does seem appea= ling for use cases such as a "moderate latency" streaming service= =C2=A0that attempts to reduce video stalls by sending "discardable&quo= t; frames using QUIC datagrams.
--0000000000003b1c8a05a591d1de--