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

From: Robert Wilton <[email-masked]>
Date: Tue, 19 Jan 2016 10:45:54 +0000

Hi,

I had a few questions regarding draft-ietf-netconf-restconf-09:

1. Is the expectation that RESTCONF only supports HTTP 1.1, and using 
HTTP/2 isn't supported?  Would it help if the document explicitly 
indicated which versions of HTTP are allowed?

2. Is HTTP 1.1 pipelining allowed/supported? If it is supported then 
does there need to be any statement made about when the requests are 
serviced and how they are ordered relative to each other?

3. Even if HTTP pipelining isn't supported then does there need to be 
any statement made about the relative orderings and what can be seen in 
the datastore when processing a combination of edit operations 
(PUT/PATCH/POST/DELETE) and GET requests by a single client?  I.e. from 
a client's perspective is it fair to assume that a GET request will see 
all updates to the running configuration datastore from all previous 
edit operations?

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Jan 2016 15:20:30 +0100

Hi Rob,

> indicated which versions of HTTP are allowed?

The use of HTTP/2 streams is an interesting topic, but I think it is up
to a client implementation to make sure the messages are delivered in a
correct order.

Apart from message ordering issues, do you see other differences between
HTTP 1.1 and 2 that might affect RESTCONF?

> serviced and how they are ordered relative to each other?

I don't think such a statement is needed. Pipelining would have to be
started by the client, but there seems to be no reason to do so because
RESTCONF data are not like normal web pages with a hundred or so
separate objects to fetch.

> all updates to the running configuration datastore from all previous 

I would say so.

Lada

>
> Thanks,
> Rob
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 16:05:04 +0100

> 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
what extend deployed APIs support HTTP/2 push of objects. Several APIs
seem to provide an HTTP/1.1 view on HTTP/2 sessions and thus they do
not expose the new push feature of HTTP/2.

/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/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 26 Jan 2016 16:25:56 +0100

> On 26 Jan 2016, at 16:05, Juergen Schoenwaelder <[email-masked]> wrote:
> 

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.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jan 2016 16:32:05 +0100

> *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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 26 Jan 2016 17:45:10 +0000

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 26 Jan 2016, at 16:05, Juergen Schoenwaelder
> <[email-masked]> wrote:
> > >
> > >> Apart from message ordering issues, do you see other differences
> > >> between HTTP 1.1 and 2 that might affect RESTCONF?
> > >
> > 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.
> >
> > *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
> 
> --

---

From: Robert Varga <[email-masked]>
Date: Tue, 26 Jan 2016 23:47:26 +0100

>> >all updates to the running configuration datastore from all previous

+1, assuming these do not happen concurrently on multiple HTTP sessions. 
A generic client must not assume it is the only entity talking to the 
server, though.

Bye,
Robert