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

Re: Framing and control-frame continuations

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Thu, 07 Feb 2013 07:46:55 +0000
To: Patrick McManus <pmcmanus@mozilla.com>
cc: Roberto Peon <grmocg@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <3323.1360223215@critter.freebsd.dk>
Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CAOdDvNqKxMuzvEC+p+ooZOsjUZ5Wd5V0YXrdbPHPTdFaWK_mmg@mail.gmail.com>
, Patrick McManus writes:

>[...] but it still represents 500ms of serialization time on a 1mb/s
>network..

Just because you _can_ send longer frames, doesn't mean that it is
a good idea to do so.

However, enforcing QoS by restricting frame-lengths is bad architecture,
when HTTP is being used for a lot of bulk applications as well.

>I've worked with a number of spdy devs doing server side deployments that
>make the frame size equal to the content length (assuming it fits in the
>more generous spdy frame size) and have had the forseeable problems with
>responsiveness. We can build a protocol that isn't susceptible to that, and
>we should.

It is not the protocol being "susceptible", it is developers being
under-clued.

You cannot enforce policy with a protocol.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 7 February 2013 07:47:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2013 07:47:20 GMT