Re: Striving for Compromise (Consensus?)

It appears that the reasons for the "Greg et al" proposal have been lost in
the debate and strawman arguments keep getting put up.   So here is a
reminder of what Large frames were proposed for - together without this
alternate proposal performs [as +/- 1]

Background

The HTTP2 protocol has a requirement to be able to transport large headers,
that exceed the payload size of a single frame at the current 16KB maximum
size.

To address this requirement, the current draft (13) includes the
CONTINUATION frames, 0 or more of which may be sent after a HEADERS or
PUSH_PROMISE frame to contain the large headers. There has been significant
criticism of the CONTINUATION design, including:

   -

   The total length of a HEADERS+CONTINUATION* sequence is not known until
   the last frame in the sequence is processed. A receiver that wishes to
   reject streams headers larger than a specific limit may have to process
   many frames and hold the results in memory before it discovers the header
   is too large.

[-1]

   -

   The size of header that an endpoint is prepared to receive is not known
   in advance. The only way a sender can know if a header too large is by
   attempting to send it and receiving an error in response. Error handling of
   headers may be difficult for an endpoint to handle efficiently and can
   result in the closure of the entire connection.

[-1]

   -

   The END_STREAM flag is not present on the CONTINUATION frame, thus it is
   possible for a stream to send CONTINUATION frames after a HEADERS frame
   that has the END_STREAM flag set. This is confusing and increases the
   complexity of the state machine required to process streams. It is highly
   desirable that a set END_STREAM flag truly indicates the last non control
   frame of a stream.

[-1]

   -

   There is a significant discontinuity in the code path required to
   process headers. Headers up to an indeterminate size (roughly 20-something
   KB) can be handled in a single frame. Headers that exceed this size must be
   handled in multiple frames of different types with different frame flags
   and stream control logic. Because the vast majority of headers sent
   (>99.99%) are below this indeterminate size, implementations will have a
   code path that is seldom executed and probably insufficiently tested. This
   invites poor and/or partial and/or incorrect implementation.

[-1]

   -

   Because of the HPACK compression algorithm, a sequence of
   HEADERS+CONTINUATIONS frames may not be interleaved with any other frame.
   This effectively makes the sequence a single large frame. Because of the
   simplicity of description and implementation it is proposed that it would
   be far simpler to meet the requirement of large headers by supporting large
   frames.

[+1]

This proposal has been prepared as it is possible to meet the requirements
of CONTINUATIONS without the complications and criticisms above.

This proposal addresses the issue of sending/receiving large HTTP headers
without giving endpoints and intermediaries unlimited resource commitments
nor unknown limits

[-1]


 Additional Frame Size Issues Addressed

The current draft (13) has maximum frame size of 16KB, which is an
arbitrary value that has been selected on the basis of experience to
provide a reasonable compromise between the efficiency of transmitting data
vs the quality of service for multiplexed channels.

Whilst this educated guess may be near optimal for today's networks and
traffic, it is entirely possible that some current and/or future networks
may require a different value to achieve an optimal balance. There have
already been proposals [1] put to the WG to reduce the frame size to
optimise multiplexing , as well as discussion that high capacity, low
latency networks can achieve satisfactory multiplexing quality of service
with large frame sizes.

This proposal addresses the issue that a fixed frame size does not allow
tuning multiplexing performance based on current/future experience.

[+0]

 It has also been noted that 16KB is near the middle of the peak of the
current HTTP Object size histogram [2], so that a small change in the frame
size may have a significant impact on the number of HTTP messages that can
be sent in a single frame, without significant impacts on QoS. The HTTP
Object size histogram has changed significantly over time and is expected
to continue to do so.

This proposal addresses the issue of tuning the frame size based on
experience of actual payload sizes.

[-0]

There have also been issues raised that a 16KB frame size does not allow
efficient data transfer [3] even when the end points are aware that only a
single stream is likely to be required for the imminent future, or
that a particular stream is of high priority.

This proposal addresses the issue of tuning the frame size for transport
efficiency for specific streams in specific situations.

[-1]


So anything that keep continuations as part of a normal implementations
just fails to address these concerns that were well received at the time.



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.