Re: Large Frame Proposal

Hi Roberto,

On Mon, Jul 07, 2014 at 01:21:26PM -0700, Roberto Peon wrote:
> There is also the latency tradeoff, which for many usecases is the big
> deal, and keeps being ignored.

It's not ignored, what is said is that in *some* circumstances it's not
the bigest deal and in such circumstances letting both sides agree on
how to optimally use resources is better than preventing them at the
protocol level. The example about the small NAS streaming to the TV is
a reasonably valid one. Such boxes have a very low CPU and are optimized
for sendfile() and will seriously suffer from copying data in small
chunks. There's no latency impact here, however the user sees a smooth
video.

I strongly believe that for the sake of latency keeping small frames by
default is the right thing to do and this proposal does so. It even allows
to reduce them even more if needed. Hey, if you connect to my home server,
you'll even see I negociate MSS to 512 to prevent outgoing HTTP traffic
from affecting my SSH sessions too much, so don't underestimate my concerns
with latency please :-)

> Additionally, there is the DoS consideration, as mentioned before.
> Since proxies are clients, and often even more constrained than servers,
> requirements to buffer are potentially onerous, especially given that one
> is not required to do this for HTTP today.

That's not true Roberto, proxies are required to honnor the Connection
header and to remove what is listed there, so in practice they cannot
start to forward even the smallest header because they don't know if
it will be tagged in a connection header later. And reverse-proxies
need to perform a minimum of security checks and cannot pass unverified
requests to servers (eg: with differing content-length headers). Also,
there are still a bunch of servers which send you a reset if you send
multi-packet requests (they're annoying to use with telnet), so that
practice in HTTP/1 is even further limited.

Cheers,
Willy

Received on Monday, 7 July 2014 21:22:17 UTC