Re: New Version Notification for draft-bishop-http2-extension-frames-00.txt

[Mike Bishop <[e-mail]>]

If the intermediary is forwarding a stream onto a connection with BASE_SPECIFICATION_ONLY set, it has to drop any extension frames.  This is why streams are allowed to have different treatment -- because the intermediary may have to accommodate different preferences on the back-end.  You’re correct that a client can’t know for sure whether an end-to-end extension is supported on each new stream; I hesitate to solve that by terminating the stream and eating an RTT, though.

Your concern over fragmentation is one that I’ve struggled with, too.  RFC 6709 is definitely something we should all read in depth several times as we have this discussion.  A couple elements I find relevant there:

  *
Avoiding “local/private use” ranges, because of the possibility of collisions and incompatibility between different local/private implementations
  *
Delineating in the base spec how extensions interact with unextended peers to ensure the failure modes are graceful
  *
“Protocol variations -- specifications that look very similar to the original but don’t interoperate with each other or with the original -- are even more harmful to interoperability than extensions.  In general, such variations should be avoided.”  My concern is that if we limit extensibility too sharply, this would be the outcome instead.
  *
In particular, section 4.4 suggests that a small parameter space (8 bits or less) combined with FCFS allocation is a recipe for trouble.  Vendor extensions (my draft) or stricter allocation requirements (your draft) are two solutions they note, with the respective problems of fragmentation and unregistered usage.  (Reference Dave Thaler & Mark’s recent discussions around URI schemes for an unregistered usage example.)

I think this is an area for working group discussion -- is our goal to have a more universal extension space with constrained capabilities (HTTP headers), a tightly-constrained one (WebSockets extensions), or somewhere in the middle?  That goal will inform how these drafts evolve, and it’s something neither James nor I can decide on our own.

Sent from Windows Mail

From: James M Snell<mailto:[e-mail]>
Sent: ‎Sunday‎, ‎November‎ ‎10‎, ‎2013 ‎11‎:‎20‎ ‎AM
To: Mike Bishop<mailto:[e-mail]>
Cc: HTTP Working Group<mailto:[e-mail]>

A few additional specific comments:

1. re: BASE_SPECIFICATION_ONLY ... this is currently underspecified in
the draft. Let's suppose my client establishes a stream that "travels"
through two intermediate hops on it's way to the server. The path
determined dynamically by the intermediaries. The first intermediary
allows end-to-end extension frames to pass through, but the second
intermediary does not and sends BASE_SPECIFICATION_ONLY. What should
the first intermediary do if it receives extension frames from the
client? Obviously, it cannot send those but there is nothing in the
draft that describes exactly how the intermediary ought to handle it.

 a. Should it just silently drop any extension frames it receives from
the client without notification. The problem being, of course, that
the client would have no idea that it's complete message is not
getting through
 b. Should it update it's settings with the client and say
BASE_SPECIFICATION_ONLY, while silently dropping any extension frames
it may have already received? The problem with this, of course, is
that it terminates that clients ability to send extension frames
through that first intermediary to any other endpoint that might not
have the BASE_SPECIFICATION_ONLY requirement.
 c. Should it RST_STREAM the stream with the client letting it know
that the extension frames could be passed on?

 (IMHO, (c) is obviously the best choice)

2. re: Flow control ... are end-to-end extension frames subject to
flow control, and if not, why not?

3. Strongly feel that the use of Private enterprise numbers as a
namespacing mechanism for extensions is going to encourage abuse and
non-standardization of protocol extensions. Specifically, it allows
specific vendors the ability to define, deploy and maintain their own
proprietary protocol extensions without any pressure whatsoever to
take things through standardization. IMHO, that's fairly dangerous.
Having a limited extension space with very clear processing
requirements is a significantly better option.

4. A compromise approach here would be to utilize both of the
approaches suggested by myself and Mike's draft. Specifically:

  a. Segment the existing frame type space into end-to-end and
hop-by-hop as I have suggested,
  b. Define that hop-by-hop frames MUST either be passed through
untouched or RST_STREAM returned,
  c. Define that *all* hop-by-hop frames are subject to flow-control,
  d. Define that extension end-to-end frames MUST NOT change session
state and can be silently dropped.
  e. Define a new INFO frame type that can always be silently dropped.
The structure of the INFO frame would essentially be the same as Mike
suggests in his draft. The INFO frame would be hop-by-hop, with the
intermediary having the ability to decide whether or not to forward
those on (like we currently do with PUSH_PROMISE).

This would be a much more robust and reliable approach.

- James

On Fri, Nov 8, 2013 at 11:21 AM, Mike Bishop
<[e-mail]> wrote:
> Since I was volunteered at the working group meeting to share this, here’s
> the current version of my draft.  I will re-emphasize that this is strictly
> a strawman, and any suggestions on how to improve this are more than
> welcome.
>
> Sent from Windows Mail
>
> From: [e-mail]
> Sent: ‎Friday‎, ‎November‎ ‎8‎, ‎2013 ‎11‎:‎16‎ ‎AM
> To: Mike Bishop
>
>
> A new version of I-D, draft-bishop-http2-extension-frames-00.txt
> has been successfully submitted by Mike Bishop and posted to the
> IETF repository.
>
> Filename:  draft-bishop-http2-extension-frames
> Revision:  00
> Title:   Extension Frames in HTTP/2.0
> Creation date:  2013-11-08
> Group:   Individual Submission
> Number of pages: 10
> URL:
> http://www.ietf.org/internet-drafts/draft-bishop-http2-extension-frames-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bishop-http2-extension-frames
> Htmlized:
> http://tools.ietf.org/html/draft-bishop-http2-extension-frames-00
>
>
> Abstract:
>    This document describes a proposed modification to the HTTP/2.0
>    specification to better support the creation of extensions without
>    the need to version the core protocol or invoke additional protocol
>    identifiers.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>