Re: Fragmentation for headers: why jumbo != continuation.

On 11/07/2014 8:27 a.m., Roberto Peon wrote:
> There are two separate reasons to fragment headers
> 
> 1) Dealing with headers of size > X when the max frame-size is <= X.
> 2) Reducing buffer consumption and latency.
> 
> Most of the discussion thus far has focused on #1.
> I'm going to ignore it, as those discussions are occurring elsewhere, and
> in quite some depth :)
> 
> 
> I wanted to be sure we were also thinking about #2.

We are. Or at least the people behind large frames proposal are.

> 
> Without the ability to fragment headers on the wire, one must know the size
> of the entire set of headers before any of it may be transmitted.
> 
> This implies that one must encode the entire set of headers before sending
> if one will ever do transformation of the headers. Encoding the headers in
> a different HPACK context would count as a transformation, even if none of
> the headers were modified.
> 
> This means that the protocol, if it did not have the ability to fragment,
> would require increased buffering and increased latency for any proxy by
> design.

Quite the opposite IMHO. Others have mentioned already in a roundabout
way. But here is the nutshell:

Header fragmentation (in forms similar to CONTINUATION) only reduces
buffering on the *sender*.

Proxies are a *recipient* in both traffic directions and therefore
always hit with buffering the entire sequence of fragments before they
can guarantee the set is safe to re-transmit down any shared
connections. So arguing from a proxy perspective it's 6 one way or half
a dozen the other.

The part which makes the real difference to proxies and servers, is that
receiving fragments (buffer on receiver) takes unlimited time with no
end in sight until its reached - whereas sending large frames (buffer on
sender) gives a clear size ending position up front. Which as PHK said
in earlier mails is critical data for recipients dealing with an attack
(or broken sender).

Given the size of a large frame up-front a proxy can actually stream the
start of that frame before the end has arrived if you trust the sender
will complete it cleanly.

This issue is already well-known from IPv4 protocol design and packet
routing issues that happen as a result. IIUIC the outcome of experience
with that IPv4 design was the decision to make IPv6 packets
non-fragmentable.

> 
> This is not currently true for HTTP/1-- the headers can be sent/received in
> a streaming fashion, and implementations may, at their option, choose to
> buffer in order to simplify code.

Willy T already answered this one so I shall avoid repeating the same
arguments.

Amos

Received on Friday, 11 July 2014 11:53:53 UTC