Re: Large Frame Proposal

In message <CAP+FsNed=Z0k5A4raGi3+AwS+CyWLoqbG5ixdOcfSbJkvo56xg@mail.gmail.com>, Roberto Peon wri
tes:

>That is true even with jumbo frames.
>You send a large frame size, then send one byte and wait for a while, then
>send another byte...

You can only do that with DATA frames.  The header-set has to fit a single
HEADERS frame.

Once the proxy/server has the complete header-set, it is in a much
better position to decide if this is part of a DoS attack or not and
consequently abort your DATA frame "slowlaris" attack.

The current CONTINUATION allows the DoS attack to progress before the
server has a chance to know anything it can use to decide on.

>Arguably, the jumbo-frame thing suffers more from this as, in order to get
>CPU efficiencies, one allocates a large memory buffer for this instead of
>resizing/partitioning,

Always allocating a worst-case sized buffer almost amounts to
efficiency malpractice in these days and times.

The "obvious" implementation is to read the 10 byte header first, then
find where it goes and read the rest.

A more "optimistic" implementation will read enough that the most
common "overhead" frames (at least WINDOW_UPDATE) fit in the first read,
and suffer the minor hit of copying a few tens of bytes if the
frame was not one of these.

>The announced size of a frame doesn't change anything w.r.t. the DoS
>surface.

No, but it does help interop by offering clients useful information.

For instance the perviously mentioned CERN bulk-transfer application
could remove the brakes right up front, and go directly to very 
large frames.

It will also save our bacon if experience shows that the data sets that
caused the 16KB limit to be chosen were not representative of the
full universe of HTTP/2 candidates.

>> Also, telling users that their video is slow because we want to ensure that
>> their TV gets a fair share of their home network's bandwidth to their NAS
>> will make them laugh at best, given that they're usually watching a single
>> video at once on a given screen.
>
>Note that the typical thought is that 'bigger is better', though we know it
>to not be true w.r.t. latency.

Unless you only have a single stream, moving a very large file, in which
case it makes a heck of a difference to performance and latency.

Such applications are plentiful, for instance in pretty much any
electronic document journaling system or document retrival system.

-- 
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 20:35:44 UTC