W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: should tools like wget implement HTTP 2.0?

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Sun, 3 Nov 2013 15:40:41 -0800
Message-ID: <CAA4WUYjEhroG91KDDWpc0_Vq2Tu=HZfqE72xDSQ+aG3xrLvN7A@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
I don't think Firefox sends a window update per data frame (I'd be
surprised). But as discussed previously, the data frame overhead is pretty
low, and having smaller frames lets you be more responsive (send control
frames as needed, interleave other perhaps higher priority data frames from
other streams, etc). See this email from Patrick from before:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0650.html.


On Sun, Nov 3, 2013 at 3:18 PM, Peter Lepeska <bizzbyster@gmail.com> wrote:

> Interesting. I hadn't realized that window updates would be sent as often
> as once per frame but that makes sense. Does Firefox do this? Are you using
> smaller than max frames during large transfers in order to send window
> updates more frequently?
>
> Thanks,
>
> Peter
>
>
> On Sun, Nov 3, 2013 at 1:33 PM, Patrick McManus <mcmanus@ducksong.com>wrote:
>
>>
>> On Nov 3, 2013 11:20 AM, "Peter Lepeska" <bizzbyster@gmail.com> wrote:
>> >
>> > A related point...uploading and downloading large numbers of data
>> frames over the same connection is problematic b/c the WINDOW_UPDATE frames
>> will get blocked behind data frames in each direction,
>>
>> Hopefully not. Just use small frame sizes so you can inject update at
>> will.. Using small frames and not over buffering is pretty much always
>> needed to make priority mux work.
>>
>> Bufferbloat at a lower layer is a problem.. But its the same problem for
>> a 2 TCP flow alternative
>>
>
>
Received on Sunday, 3 November 2013 23:41:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC