Re: [Netconf] HTTP/2 support in draft-ietf-netconf-restconf-09

At this point, Restconf does not expose the necessary capabilities to fully utilize HTTP/2.  Previously the NETCONF WG talked about this in a thread:
  https://www.ietf.org/mail-archive/web/netconf/current/msg10429.html

There are several nice things full HTTP/2 can provide, should the capabilities be exposed above Restconf:
- Prioritized TCP stream de-queuing 
- Avoiding head-of-line blocking from elephant flows
- Per-stream flow control

For more, see slides 5 & 6 from IETF 94
  https://www.ietf.org/proceedings/94/slides/slides-94-netconf-5.pdf
(This deck is framed in terms of subscriptions, but the points are equally valid for normal TCP streams.)

Although I would love to see this in the initial Restconf RFC, I have always expected the such a specification would be in a subsequent draft.

Eric

> From: Juergen Schoenwaelder, Tuesday, January 26, 2016 10:32 AM
> 
> On Tue, Jan 26, 2016 at 04:25:56PM +0100, Ladislav Lhotka wrote:
> >
> > > On 26 Jan 2016, at 16:05, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > On Tue, Jan 26, 2016 at 03:20:30PM +0100, Ladislav Lhotka wrote:
> > >
> > >> Apart from message ordering issues, do you see other differences
> > >> between HTTP 1.1 and 2 that might affect RESTCONF?
> > >
> > > I think notification delivery could be done more elegant in HTTP/2
> > > using Server Push (section 8 of RFC 7540) but then I do not know to
> >
> > My understanding is that HTTP/2 server push cannot be used as a replacement
> for SSE or Websockets, because the server has to send the PUSH_PROMISE
> frame also containing "expected" request headers to which the server is about
> to send responses.
> >
> > So, for example, a HTTP/2 server, after receiving
> >
> > GET /.well-known/host-meta
> >
> > *might* use server push for sending yang-library information right away,
> because the client is likely to need it, too. But I don't think server push can be
> used for implementing notifications.
> >
> 
> Because notifications are not modelled as first class resources? I doubt this
> matters. The notification stream could be a resource and then you simply craft
> GET requests that return the notification content. In fact, RESTCONF already has
> 'event stream resources'.
> But at the end, wide-spread support in HTTP APIs does matter and it is perhaps
> too early to tell.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf