- 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>
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 UTC