Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

Andy Green <andy@warmcat.com> Mon, 16 October 2017 02:58 UTC

Return-Path: <andy@warmcat.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 8CF98133341 for <hybi@ietfa.amsl.com>; Sun, 15 Oct 2017 19:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SphjNamWKDE5 for <hybi@ietfa.amsl.com>; Sun, 15 Oct 2017 19:58:42 -0700 (PDT)
Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E906B126BF3 for <hybi@ietf.org>; Sun, 15 Oct 2017 19:58:41 -0700 (PDT)
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, Cory Benfield <cory@lukasa.co.uk>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> <CAOdDvNqhaTJmLcEk3CwBBaAbdOroc4U46z+nJzC7+chd1ErSDA@mail.gmail.com> <FEBB57D4-E841-4F45-9B62-81FFC653FF70@lukasa.co.uk> <0F93FB58-579D-4F52-8F22-5FEAFBC99165@warmcat.com> <CAOdDvNpCVxsaKEzoW3EWsK1hmWSBPOP+GHnK-DcP4QO4om_khQ@mail.gmail.com> <f4bb6b5c-b12e-dc59-6faa-15588b692574@warmcat.com> <CABkgnnUfDwYmxi72f-x=z=iwf4+3L_rcLqufJRYvEMpP=Fb3MA@mail.gmail.com>
From: Andy Green <andy@warmcat.com>
Message-ID: <a4229e61-fb04-30b1-f2c7-a862645d0059@warmcat.com>
Date: Mon, 16 Oct 2017 10:57:53 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
In-Reply-To: <CABkgnnUfDwYmxi72f-x=z=iwf4+3L_rcLqufJRYvEMpP=Fb3MA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/waEkeRi3JQSQnyoVOfbJFsSuq04>
Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Oct 2017 02:58:43 -0000


On 10/16/2017 10:51 AM, Martin Thomson wrote:
> On Mon, Oct 16, 2017 at 1:38 PM, Andy Green <andy@warmcat.com>; wrote:
>> Here's what I think it means for RTT... first the default as it is
>>
>> Client                          Server
>>
>>   - SETTINGS                      - SETTINGS
>>   - GET /index.html
>>                                   - 200 HEADERS + DATA
>>
>>   - :method CONNECT
>>                                   - 200 HEADERS
>>
>>   - DATA ws handshake
>>                                   - DATA ws handshake final
>>
>>   - DATA ...                      - DATA...
>>
>> So after the h2 link is up, he needs 3 x roundtrips to send some ws data.
> 
> I think that you are exaggerating the cost here.  The ws handshake and

Eh... why do you say that?  It takes less than 3 RTs?

> CONNECT can be sent together.  The only real burden that Patrick's
> design adds is the need to test that the server is willing to use this
> design.

Maybe it's not clear from the formatting, but I based this from p4 of 
Patrick's draft, here is the original

   [[ From Client ]]                        [[ From Server ]]

                                            SETTINGS
                                            ENABLE_CONNECT_PROTOCOL = 1

   HEADERS + END_HEADERS
   :method = CONNECT
   :protocol = websocket
   :scheme = wss
   :path = /chat
   :authority = server.example.com:443

                                            HEADERS + END_HEADERS
                                            :status = 200

   DATA
   GET /chat HTTP/1.1
   Host: server.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: http://example.com
   Sec-WebSocket-Protocol: chat, superchat
   Sec-WebSocket-Version: 13

                                            DATA
                                            HTTP/1.1 101 Plead The Fifth
                                            Upgrade: websocket
                                            Connection: Upgrade
                                            Sec-WebSocket-Accept:
                                             s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
                                            Sec-WebSocket-Protocol: chat

   DATA
   WebSocket Data

                                            DATA + END_STREAM
                                            WebSocket Data

   DATA + END_STREAM
   WebSocket Data


That is 3 RTT, right?

> FWIW, if this were me, I would look at trimming the websocket
> handshake instead.  Much of the overhead there is what will hurt the

He needs to support dumb http/1 ws clients that find themselves hitching 
a ride on a h2 bundle.  So they need all the headers they expect.

That's why I don't suggest any changes there, but as an optimization for 
h2-aware ws client skip all that legacy junk and just provide the end 
result in the PUSH_PROMISE.

> overall latency.  If you took the setting as an indication that this
> was an acceptable protocol, you could remove all the Upgrade business
> and just start sending ws frames.  But I think that Patrick is right
> to start with the minimal thing; I would recommend only doing that
> with a new protocol identifier.

That is what I suggested on both counts :-)

-Andy