Re: [hybi] hybi Digest, Vol 94, Issue 1
Scott Morgan <scott@adligo.com> Tue, 23 July 2019 15:49 UTC
Return-Path: <scott@adligo.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599141201C3 for <hybi@ietfa.amsl.com>; Tue, 23 Jul 2019 08:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=adligo-com.20150623.gappssmtp.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 pP_aCP66sLd2 for <hybi@ietfa.amsl.com>; Tue, 23 Jul 2019 08:49:01 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 56F6812025F for <hybi@ietf.org>; Tue, 23 Jul 2019 08:49:01 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id z4so42449082qtc.3 for <hybi@ietf.org>; Tue, 23 Jul 2019 08:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adligo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=K+gSG9MQX1Oz4e4wlhwMx+IlejsiLvkHFyqUgwX2isw=; b=XdiP/aBWMBO2JnCT2wYQYPViqne/1lwEnRFKRmvH215eiyVY+KSOth+dAsP6Lz6K17 xDggxgFYZbGu7IZiQChZTjqpTSsnmZx5eRzfebDObcMdkjpvVmKmpvIwhVRR8IGy8gGV WXruI+vlvw3pfTkAuAJ9JrDdQ6RGw3T3rY0G/NitcvbzSOiuK7+xXAPEBnoS6m8XKMAM sqYb23SeALJW35f9IgCfZFJR6rB8g6HDFvII3RALsqyIfGFGz5qk+kAuOI9S6geXpeBO OtBXrGIAC3QL4l+fyxDHBQHb7jH0klk4yy2DKKB0tlUqtr2KLQsZSgd7R/qPup21mcs6 gUuQ==
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; bh=K+gSG9MQX1Oz4e4wlhwMx+IlejsiLvkHFyqUgwX2isw=; b=qXDoZmdFBwz4GNdMM6UML5Nl3y6lyG8NI00qiX6R1/wxoGq5OjFJFm2MRK9WqVhaQI KIpnkz9HLPjionGv/vCy0P6y8Vx6XFX8XH7NPwD3/djKguaJ2kgEUoZEfaQpiB0xvenn UxIGJMJFqSPVyHZ03woH3+gcjWrE3DevYYKXmftK3TvvAcXRcNPREnMAOcWzYCpF5ZgK fklaCy92a5qw9djIxWURJXfLT3L/NKytoOieiCZKti7ovFk1HxhaPMEa4xdzSEGuOodZ 6KyNlDVKdlGRhVOrvltg+W9SiC/TISLGPOiAd5QPlbFFfH/NokEBU4tjrvyuDV5wKzmm c4cQ==
X-Gm-Message-State: APjAAAURmb5T0P6Cfw5f3CBQttRJhT+doN7NiNt7XljoP8zx2wGFHcr1 f7/VQ5NAYMD3CKaJ7vsf+W4BOTqlob7IRgL78b9ExaM2
X-Google-Smtp-Source: APXvYqxLE77JqpdiaANm+7ibIPsFvZPOMuguTS2wDt0iPQhXEqLXaRbwqJGxMwjvA6Fb8Y6bUeRsWljx+uV143OZDqw=
X-Received: by 2002:a05:6214:47:: with SMTP id c7mr1140069qvr.3.1563896939869; Tue, 23 Jul 2019 08:48:59 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.2148.1563896276.9467.hybi@ietf.org>
In-Reply-To: <mailman.2148.1563896276.9467.hybi@ietf.org>
From: Scott Morgan <scott@adligo.com>
Date: Tue, 23 Jul 2019 10:48:48 -0500
Message-ID: <CANEdHmjGCG0-gvAYTkLQs=ErSFc3DQP+3wNNOMdwvB25Bbom1A@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="000000000000910d60058e5b217a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/BX_XTSqf_D2jq5PeOLFcVTmUbfE>
Subject: Re: [hybi] hybi Digest, Vol 94, Issue 1
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 15:49:07 -0000
+1 to WebTransport, I have been building that sort of thing in to applications directly, so it would eventually reduce code that I need to manage/maintain. https://tools.ietf.org/html/draft-adligo-hybi-asbp-02 On Tue, Jul 23, 2019 at 10:39 AM <hybi-request@ietf.org> wrote: > Send hybi mailing list submissions to > hybi@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/hybi > or, via email, send a message with subject or body 'help' to > hybi-request@ietf.org > > You can reach the person managing the list at > hybi-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of hybi digest..." > > > Today's Topics: > > 1. WebTransport Side Meeting (Tuesday, 15:20) (Victor Vasiliev) > 2. Re: WebTransport Side Meeting (Tuesday, 15:20) (Andy Green) > 3. Re: WebTransport Side Meeting (Tuesday, 15:20) (Eric Kinnear) > 4. Re: [dispatch] WebTransport Side Meeting (Tuesday, 15:20) > (Peter Thatcher) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Jul 2019 16:36:19 -0400 > From: Victor Vasiliev <vasilvv@google.com> > To: dispatch@ietf.org, David Schinazi <dschinazi@google.com> > Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group > <ietf-http-wg@w3.org>, hybi@ietf.org > Subject: [hybi] WebTransport Side Meeting (Tuesday, 15:20) > Message-ID: > < > CAAZdMacqbqYVs4MeoE-ahukgLzf0+nNhNip4HTGThobXhqCceQ@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello everyone, > > Today, at the dispatch working group meeting (18:10), I am going to present > WebTransport. WebTransport is a protocol framework that allows multiplexed > and datagram-oriented transport protocols to be used by the web > applications (think ?WebSocket for UDP?). > > Since it?s quite likely we will run out of time during dispatch, I > scheduled a side-meeting to discuss this in more depth. Below are the side > meeting details. > > *Time:* Tuesday, 15:20 ~ 16:50 > *Place:* Room C2 (21st floor) > *Organizers:* Victor Vasiliev, David Schinazi > *Agenda:* > > 1. A more in-depth overview of WebTransport. > 2. Discussion of the overall design and the use cases. > 3. As time permits, some of the major outstanding design issues in Web > transport, e.g.: > - What fallback protocol to use? > - How to multiplex streams and datagrams within a single connection? > - Can we let web applications do their own congestion control? > - Should WebTransport sessions have URLs associated with them? > > As usual, here are some helpful links: > > - WebTransport overview: > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > - QuicTransport: > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > - Http3Transport: > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > - Web API Spec draft: https://wicg.github.io/web-transport/ > - Discussion on use cases: > https://discourse.wicg.io/t/webtransport-proposal/3508 > > Cheers, > Victor. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/hybi/attachments/20190722/f43b7819/attachment.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 22 Jul 2019 13:59:57 -0700 > From: Andy Green <andy@warmcat.com> > To: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>, > dispatch@ietf.org, David Schinazi <dschinazi@google.com> > Cc: hybi@ietf.org, IETF QUIC WG <quic@ietf.org>, HTTP Working Group > <ietf-http-wg@w3.org> > Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20) > Message-ID: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 7/22/19 1:36 PM, Victor Vasiliev wrote: > > Hello everyone, > > > > Today, at the dispatch working group meeting (18:10), I am going to > > present WebTransport. WebTransport is a protocol framework that allows > > multiplexed and datagram-oriented transport protocols to be used by the > > web applications (think ?WebSocket for UDP?). > > "Historically, web applications that needed bidirectional data stream > between a client and a server could rely on WebSockets [RFC6455], a > message-based protocol compatible with Web security model. However, > since the abstraction it provides is a single ordered stream of > messages, it suffers from head-of-line blocking (HOLB), meaning that > all messages must be sent and received in order even if they are > independent and some of them are no longer needed. This makes it a > poor fit for latency sensitive applications which rely on partial > reliability and stream independence for performance." > > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary > fragmentation of messages allowing interleaving with control frames. > > ws-over-h2 allows you to can the h2 stream when you want as well. > > " Each new stream would require a WebSocket handshake to agree on > application protocol used, meaning that it would take at least one > RTT for each new stream before the client can write to it." > > Yes it was knowingly done as a hack to try to encourage uptake from > browser vendors... it's not really integrated into the encapsulating > protocol. > > > * WebTransport overview: > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > * QuicTransport: > > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > > * Http3Transport: > > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > > There's no h2 transport implementation? > > Not everything that might want to use this will get h3 capability in a > reasonable timeframe. If there's more momentum behind it than RFC8441 > there's probably room for a generic long-lived bidirectional extension > to h2 either reusing DATA or a new frame type. > > It's a good idea to have it ride on other protocols. Not doing this > really hurt RFC6455 ws since deploying it usually needed extra, > different servers with the attendant difficulties interoperating with > other protocols. > > I really suggest thinking through the effects of not having an RFC6455 > type subprotocol (unless I failed to spot it). It really makes an > implicit assumption about what the stream will carry that doesn't scale > beyond one server carrying one thing. That's not how things tend to pan > out if the protocol is useful. The url path could be hacked to imply > the subprotocol but if that's not standardized it's still a mess. And > the subprotocol binding may be orthogonal to the url layout complicating > things needlessly. > > -Andy > > > * Web API Spec draft: https://wicg.github.io/web-transport/ > > * Discussion on use cases: > > https://discourse.wicg.io/t/webtransport-proposal/3508 > > > > Cheers, > > ? Victor. > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > > > > > > ------------------------------ > > Message: 3 > Date: Mon, 22 Jul 2019 17:29:09 -0400 > From: Eric Kinnear <ekinnear@apple.com> > To: Andy Green <andy@warmcat.com> > Cc: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>, > dispatch@ietf.org, David Schinazi <dschinazi@google.com>, > hybi@ietf.org, IETF QUIC WG <quic@ietf.org>, HTTP Working Group > <ietf-http-wg@w3.org> > Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20) > Message-ID: <E8ABA72D-541E-45BE-B032-237CAC37F3A8@apple.com> > Content-Type: text/plain; charset=utf-8 > > > > > On Jul 22, 2019, at 4:59 PM, Andy Green <andy@warmcat.com> wrote: > > > > > > > > On 7/22/19 1:36 PM, Victor Vasiliev wrote: > >> Hello everyone, > >> Today, at the dispatch working group meeting (18:10), I am going to > present WebTransport. WebTransport is a protocol framework that allows > multiplexed and datagram-oriented transport protocols to be used by the web > applications (think ?WebSocket for UDP?). > > > > "Historically, web applications that needed bidirectional data stream > > between a client and a server could rely on WebSockets [RFC6455], a > > message-based protocol compatible with Web security model. However, > > since the abstraction it provides is a single ordered stream of > > messages, it suffers from head-of-line blocking (HOLB), meaning that > > all messages must be sent and received in order even if they are > > independent and some of them are no longer needed. This makes it a > > poor fit for latency sensitive applications which rely on partial > > reliability and stream independence for performance." > > > > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary > fragmentation of messages allowing interleaving with control frames. > > > > ws-over-h2 allows you to can the h2 stream when you want as well. > > > > " Each new stream would require a WebSocket handshake to agree on > > application protocol used, meaning that it would take at least one > > RTT for each new stream before the client can write to it." > > > > Yes it was knowingly done as a hack to try to encourage uptake from > browser vendors... it's not really integrated into the encapsulating > protocol. > > > >> * WebTransport overview: > >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > >> * QuicTransport: > >> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > >> * Http3Transport: > >> https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > > > > There's no h2 transport implementation? > > > > Not everything that might want to use this will get h3 capability in a > reasonable timeframe. If there's more momentum behind it than RFC8441 > there's probably room for a generic long-lived bidirectional extension to > h2 either reusing DATA or a new frame type. > > Definitely agree! I know that we?ve been chatting a bit with Victor about > https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/ > which aims to provide this, and I think it would be worth making sure that > this works nicely with WebTransport. > -00 for that document covers effectively what you?d get with a new frame > type, and -01 extends 8441 to cover more than just WebSockets with the > extended CONNECT handshake. > I don?t have a particularly strong preference for the mechanism used, but > rather care more about the outcome ? very much agree that this is a useful > component. > > Thanks, > Eric > > > > > It's a good idea to have it ride on other protocols. Not doing this > really hurt RFC6455 ws since deploying it usually needed extra, different > servers with the attendant difficulties interoperating with other protocols. > > > > I really suggest thinking through the effects of not having an RFC6455 > type subprotocol (unless I failed to spot it). It really makes an implicit > assumption about what the stream will carry that doesn't scale beyond one > server carrying one thing. That's not how things tend to pan out if the > protocol is useful. The url path could be hacked to imply the subprotocol > but if that's not standardized it's still a mess. And the subprotocol > binding may be orthogonal to the url layout complicating things needlessly. > > > > -Andy > > > >> * Web API Spec draft: https://wicg.github.io/web-transport/ > >> * Discussion on use cases: > >> https://discourse.wicg.io/t/webtransport-proposal/3508 > >> Cheers, > >> Victor. > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 23 Jul 2019 11:37:04 -0400 > From: Peter Thatcher <pthatcher@google.com> > To: Eric Kinnear <ekinnear=40apple.com@dmarc.ietf.org> > Cc: Andy Green <andy@warmcat.com>, Victor Vasiliev > <vasilvv=40google.com@dmarc.ietf.org>, hybi@ietf.org, David > Schinazi > <dschinazi@google.com>, dispatch@ietf.org, HTTP Working Group > <ietf-http-wg@w3.org>, IETF QUIC WG <quic@ietf.org> > Subject: Re: [hybi] [dispatch] WebTransport Side Meeting (Tuesday, > 15:20) > Message-ID: > < > CAJrXDUE2P8WiM783AXg2BgCXi_goHFMbYTP9PkPa4mof0MJYaA@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > At a quick glance, > > https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/?include_text=1 > seems > like a decent fit for the WebTransport API. It seems better than trying > to fit the WebSocket API. But do we expect people to implement it on > servers before they implement QUIC? I suppose even if it takes longer, it > may have the advantage of working on more networks than QUIC and HTTP/3 > potentially (for networks that still block UDP, for example). > > > > On Mon, Jul 22, 2019 at 5:29 PM Eric Kinnear <ekinnear= > 40apple.com@dmarc.ietf.org> wrote: > > > > > > > > On Jul 22, 2019, at 4:59 PM, Andy Green <andy@warmcat.com> wrote: > > > > > > > > > > > > On 7/22/19 1:36 PM, Victor Vasiliev wrote: > > >> Hello everyone, > > >> Today, at the dispatch working group meeting (18:10), I am going to > > present WebTransport. WebTransport is a protocol framework that allows > > multiplexed and datagram-oriented transport protocols to be used by the > web > > applications (think ?WebSocket for UDP?). > > > > > > "Historically, web applications that needed bidirectional data stream > > > between a client and a server could rely on WebSockets [RFC6455], a > > > message-based protocol compatible with Web security model. However, > > > since the abstraction it provides is a single ordered stream of > > > messages, it suffers from head-of-line blocking (HOLB), meaning that > > > all messages must be sent and received in order even if they are > > > independent and some of them are no longer needed. This makes it a > > > poor fit for latency sensitive applications which rely on partial > > > reliability and stream independence for performance." > > > > > > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary > > fragmentation of messages allowing interleaving with control frames. > > > > > > ws-over-h2 allows you to can the h2 stream when you want as well. > > > > > > " Each new stream would require a WebSocket handshake to agree on > > > application protocol used, meaning that it would take at least one > > > RTT for each new stream before the client can write to it." > > > > > > Yes it was knowingly done as a hack to try to encourage uptake from > > browser vendors... it's not really integrated into the encapsulating > > protocol. > > > > > >> * WebTransport overview: > > >> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > >> * QuicTransport: > > >> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > > >> * Http3Transport: > > >> https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > > > > > > There's no h2 transport implementation? > > > > > > Not everything that might want to use this will get h3 capability in a > > reasonable timeframe. If there's more momentum behind it than RFC8441 > > there's probably room for a generic long-lived bidirectional extension to > > h2 either reusing DATA or a new frame type. > > > > Definitely agree! I know that we?ve been chatting a bit with Victor about > > https://datatracker.ietf.org/doc/draft-kinnear-httpbis-http2-transport/ > > which aims to provide this, and I think it would be worth making sure > that > > this works nicely with WebTransport. > > -00 for that document covers effectively what you?d get with a new frame > > type, and -01 extends 8441 to cover more than just WebSockets with the > > extended CONNECT handshake. > > I don?t have a particularly strong preference for the mechanism used, but > > rather care more about the outcome ? very much agree that this is a > useful > > component. > > > > Thanks, > > Eric > > > > > > > > It's a good idea to have it ride on other protocols. Not doing this > > really hurt RFC6455 ws since deploying it usually needed extra, different > > servers with the attendant difficulties interoperating with other > protocols. > > > > > > I really suggest thinking through the effects of not having an RFC6455 > > type subprotocol (unless I failed to spot it). It really makes an > implicit > > assumption about what the stream will carry that doesn't scale beyond one > > server carrying one thing. That's not how things tend to pan out if the > > protocol is useful. The url path could be hacked to imply the > subprotocol > > but if that's not standardized it's still a mess. And the subprotocol > > binding may be orthogonal to the url layout complicating things > needlessly. > > > > > > -Andy > > > > > >> * Web API Spec draft: https://wicg.github.io/web-transport/ > > >> * Discussion on use cases: > > >> https://discourse.wicg.io/t/webtransport-proposal/3508 > > >> Cheers, > > >> Victor. > > >> _______________________________________________ > > >> hybi mailing list > > >> hybi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/hybi > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/hybi/attachments/20190723/6a4ac121/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > ------------------------------ > > End of hybi Digest, Vol 94, Issue 1 > *********************************** > -- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating <https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256> https://github.com/adligo By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI <https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI>*
- Re: [hybi] hybi Digest, Vol 94, Issue 1 Scott Morgan