Re: Making extensibility cheap

The deadlock is an interesting point.  If we introduce fragmentation in HTTP/2, the transport folks may renew their complaints that we're reimplementing their layer, but I understand the concern.  I look forward to discussing possible solutions, though I don't have one off the top of my head.

Sent from Windows Mail

From: Tatsuhiro Tsujikawa<mailto:tatsuhiro.t@gmail.com>
Sent: ?Tuesday?, ?June? ?3?, ?2014 ?8?:?10? ?PM
To: Martin Thomson<mailto:martin.thomson@gmail.com>
Cc: HTTP Working Group<mailto:ietf-http-wg@w3.org>


2014/06/04 9:04 "Martin Thomson" <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>:
>
> I've been somewhat convinced by Mike Bishop's arguments for restoring
> extensibility[1].
>
> What I find hard to swallow is the associated cost.  I think that
> Mike's proposal could be trimmed further.  So I'm going to take up the
> challenge.
>
> Here's what I think we absolutely need:
>
> 1. A way to negotiate the use of hop-by-hop extensions.
> 2. A way to carry end-to-end extensions.
> 3. Extensibility for settings, frames and error codes.
>
> To that end, here's my proposed reduction, which I think is largely
> keeping with the spirit of Mike's draft:
>
> Extensibility
>
> As Mike suggests, we can open a few IANA registries for business.
> That's text we can restore from old drafts.  Easy.
>
> I agree that we need more space for settings than 8 bits, but I'm
> going to be aggressive and suggest that 16 bits is enough.  We can
> reserve some portion of that space for mucking around (a quarter is
> what I'd suggest, but I don't care).
>
> End-to-end
>
> Here I'm going to suggest something far more limited than what Mike
> does.  I think that we can get away with an end-to-end, flow
> controlled, ordered frame.  A new frame type, modelled on Mike's
> should work here.  The new frame type would include a 32-bit extension
> ID, for which we can open a registry; we could piggyback on the PEN
> registry (private enterprise number); or, we could recommend random
> selection.  Again, I care not about these details and will go with
> what people seem to like most.
>
> We could do something more with optional flow control, optional
> end-to-end and optional ordering, but I think that is altogether too
> much optionality.
>
> I'm aware that forcing flow control here might be controversial, but I
> think that if we require intermediaries to forward this - and I think
> we have to - this is the only good option.
>

If flow control is forced, payload of this new frame must be able to be fragmented in arbitrary size to avoid deadlock just like DATA frame, which Johnny and I wrote in the other thread.  If both ends started to send new frames and blocked in the middle of their payload due to exhaustion of window, deadlock will happen.

Best regatds,
Tatsuhiro Tsujikawa

> Negotiation
>
> I think that this doesn't need a new "EXTENSIONS" frame, I think that
> we can use settings.  Each peer can set a setting to indicate that
> they support feature X and if both support the feature, then the
> state-affecting components of that feature can be activated.
>
> Otherwise, all error codes map to INTERNAL_ERROR (or some new error
> code we define that has equivalent semantics, i.e., none); all unknown
> frame types are dropped; and all settings are ignored.
>
> Note that this is important.  Unless you negotiate, only the special
> "EXTENSION" frame will traverse intermediaries.
>
> Advice Column
>
> Mike's draft offers good guidance for extension designers.  I think we
> need to crib some of that text.  Suggesting that an extension deal
> with translating to and from HTTP/1.1, or dealing with peers that
> don't support the extension is motherhood and apple pie.  More
> important though is establishing the parameters for extension.  Much
> of the above will need to reside in this section.
>
> I am going to try to turn out some proposed text for this on the plane
> tomorrow, in case this is what we decide to pursue.
>
> --Martin
>
> [1] in draft-bishop-http2-extension-frames
>