W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Large Frame Proposal

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 07 Jul 2014 21:58:13 +0000
To: Roberto Peon <grmocg@gmail.com>
cc: Willy Tarreau <w@1wt.eu>, Johnny Graettinger <jgraettinger@chromium.org>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <78230.1404770293@critter.freebsd.dk>
In message <CAP+FsNdq4O0awp=B=5EPFh4y5XN=KKM2xr6DvcVkrMKpSzDn6Q@mail.gmail.com>, Roberto Peon wri
tes:

>In the response path, gateways can have significantly more leeway than the
>proposed change (requiring buffering) would allow-- today I can know, by
>virtue of the fact that I'm running both the gateway and the server, that
>the server isn't going to do anything that can't be checked on a key-value
>basis (as opposed to a full-headers basis), and requiring buffering for
>each gateway on that path induces more latency than needs to be there, [...]

Can you please tell me, blow by blow, packet by packet, where that latency
comes from, because I can't find a place to fit it in ?

Just because you get your HEADERS in a single frame doesn't mean you cannot
process it byte by byte (or MTU by MTU) if you want to ?

The only real difference is that you get to know up front how much
will be coming your way.  I have a hard time seeing how that can
hurt your latency ?

-- 
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 Monday, 7 July 2014 21:58:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC