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

On Fri, Nov 8, 2013 at 4:04 PM, Mike Bishop
<Michael.Bishop@microsoft.com> wrote:
> We discussed some of this at the Bellevue interim….
>
>
>
> With regard to HbH vs. E2E:
>
> ·         End-to-end on stream zero isn’t possible, since there’s nowhere to
> forward them
>
> ·         On-stream frames mix hop-by-hop and end-to-end
>
> In order to simplify the model, there was general consensus that we could
> simplify this considerably by reducing it to two states:
>
> ·         Stream zero is hop-by-hop, and ignored if not understood
>
> ·         On-stream is end-to-end and may be dropped or forwarded
>

-1 on the "may be dropped". As I've mentioned before, silently
dropping end-to-end frames could significantly impact the semantics of
the stream data and could have very bad unintended side effects. The
result is that end-to-end extension frames become impossible to rely
upon. The better (and more reliable) option is to require that
end-to-end frames are either passed through untouched or the stream is
closed with an RST_STREAM if the endpoint does not intend to pass them
along.

> While I’m not inherently opposed to also allowing on-stream hop-by-hop
> frames since the protocol has them, it does increase the handling complexity
> some.
>

If the handling requirements are clearly articulated, there is no harm
in allowing them. It would be clear: an unknown hop-by-hop frame on a
stream could be dropped safely without changing the semantics of the
end-to-end message.

>
>
> With regard to your space partitioning idea, it doesn’t solve type
> exhaustion.  In fact, it exacerbates it since one type can be exhausted
> while types still remain in the other half of the space.  If we allow a mix
> of E2E and HbH frames on-stream, I’d prefer a flag to the MSB approach.
>

I don't want to "solve" the type exhaustion because I'm not convinced
that it's a problem in the long run. Keeping the extension space
limited ought to discourage bad behavior. Using a flag is problematic
for two reasons: (1) the flag value space is far more limited than the
available type identifier space and (2) it would mean that a single
frame type could be sent end-to-end OR hop-by-hop, potentially
muddying the semantics significantly (an extension frame would need to
clearly indicate what behavior is appropriate in either case).

>
>
> The idea of having a private-use range for use during development followed
> by registration and a shift to IANA-assigned values is an option, but given
> that some of our numbers tend to broadly deploy things that are still under
> active development, that complicates both the transition from the unassigned
> to assigned versions and the ability of extensions to coexist.
>

Again, the limited value space ought to discourage bad behavior.

- James

>
>
> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Friday, November 8, 2013 12:13 PM
> To: Mike Bishop
> Cc: HTTP Working Group
> Subject: Re: New Version Notification for
> draft-bishop-http2-extension-frames-00.txt
>
>
>
> On Fri, Nov 8, 2013 at 12:06 PM, James M Snell <jasnell@gmail.com> wrote:
>
>> It's great to see work being done on the extension model but I'm not
>
>> convinced that the approach you suggest in this draft is the best way
>
>> forward.
>
>>
>
>> The approach that I would like to see is this:
>
>>
>
>> For Frames:
>
>>
>
>> 1. Clearly define the notion that some frames are *always* end-to-end,
>
>> while others are *always* hop-by-hop 2. Clearly differentiate these
>
>> types using the MSB of the frame type.
>
>> If the MSB is set, the frame is end-to-end 3. Specify that end-to-end
>
>> frames are *always* subject to flow control 4. Change the type of the
>
>> DATA frame to 0x80 5. Dedicate 10 frame types at the top of each range
>
>> (0xF5-FF and
>
>> 0x75-7F) as "private use" frame types that cannot be assigned by IANA.
>
>> 6. Require that end-to-end frames are only sent on open streams
>
>> (basically, whenever a DATA frame can be sent)
>
>
>
> Missed one:
>
>
>
>   7. Require that implementations ignore-but-forward unknown end-to-end
> frames; while allowing them to ignore-and-drop unknown hop-by-hop frames...
> with the option of signaling an error if they so choose.
>
>
>
>
>
>>
>
>> For Settings:
>
>>
>
>> Dedicate some portion of the possible range of settings as "private
>
>> use" that cannot be assigned by IANA
>
>>
>
>> - James
>
>>
>
>> On Fri, Nov 8, 2013 at 11:21 AM, Mike Bishop
>
>> <Michael.Bishop@microsoft.com> 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: internet-drafts@ietf.org
>
>>> 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-fram
>
>>> es-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
>
>>>

Received on Sunday, 10 November 2013 18:12:32 UTC