Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16

[Martin Bjorklund <[e-mail]>]

Qin Wu <[e-mail]> wrote:
> 
> 
> -----邮件原件-----
> 发件人: Martin Bjorklund [mailto:[e-mail]] 
> 发送时间: 2018年9月19日 15:25
> 收件人: Qin Wu
> 抄送: evoit=[e-mail]; [e-mail];
> [e-mail]
> 主题: Re: [Netconf] activate-configured-subecription - WGLC
> subscribed-notifications-16
> 
> Qin Wu <[e-mail]> wrote:
> > 
> > 发件人: Netconf [mailto:[e-mail]] 代表 Eric Voit
> > (evoit)
> > 发送时间: 2018年9月19日 6:44
> > 收件人: Douglas Hubler; Martin Bjorklund
> > 抄送: [e-mail]
> > 主题: Re: [Netconf] activate-configured-subecription - WGLC
> > subscribed-notifications-16
> > 
> > Hi Douglas,
> > 
> > From: Douglas Hubler, September 18, 2018 5:35 PM
> > 
> > On Tue, Sep 18, 2018 at 3:40 PM Martin Bjorklund 
> > <[e-mail]<mailto:[e-mail]>> wrote:
> > So it seems you support my point to make this draft use SSE.  Then if 
> > you use HTTP/2 you (the client) can simply create one HTTP/2 stream 
> > per notification stream.  This just falls out for free with HTTP/2.
> > 
> > yes, with caveat that I haven't attempted actual implementation yet.
> > 
> > <Eric> Agree that SSE over HTTP2 should work.  However to me using SSE
> > here seems redundant as HTTP2 provides the necessary mechanisms.  But 
> > I won’t get in the way if people really do want to go in this 
> > direction.
> > 
> > [Qin]: HTTP2 provides Server Push mechanism however there are lots of 
> > drawbacks, typical one is Server Push may be blocked, therefore 
> > HTTP1.1+ SSE is favored.
> 
> But HTTP/2 server push doesn't even address the same problem; how to
> get a stream of notifs sent from the server to the client.  If I'm not
> mistaken, server push could be done w/ the GET of the SSE stream, so
> maybe server push could be used to avoid the round trip:
> 
>     client                              server
>     ------                              ------
>       |      establish-subscription    
>       |      ------------------------>    |
>       |                                   |
>       |         OK, location=SSE URL      |
>       |      <------------------------    |
>       |         PUSH_PROMISE,             |
>       |           new stream, SSE URL     |
>       |      <------------------------    |
>       |           SSE event (notif)       |
>       |      <------------------------    |
>       |           SSE event (notif)       |
>       |      <------------------------    |
>       |                                   |
>             
> [Qin]: Yes, HTTP/2 server push can save round trip, but if HTTP/2
> server push is used, two channels need to be established, one for
> establish-subscription,
> One for HTTP/2 Server Push, not sure the sequence of work flow here is
> correct

In the diagram I wrote "PUSH_PROMISE new stream" which was supposed to
indicate that the PUSH (and subsequent data) are sent in a new stream.

> , first how does establish-subscription RPC indicate server
> push support, how does server know server push should be used for
> response.

This is not specific to this draft, it is a generic HTTP/2 question,
right?  If I'm not mistaken this is taken care of by the HTTP/2 spec.

> Second, SSE event and OK, PUSH-PROMISE should be established in
> another channel or HTTP connection?

Yes, another stream, see above.

> HTTP server push has two typical drawbacks:
> 1. HTTP/2 does not guarantee that pushed resources are delivered
>    to the client in the order they were sent by the client
> 2.Server Push is optional and can be disabled by any proxy between the
> client and the server.

Again, this is a generic HTTP/2 PUSH issue.  If the client doesn't
recveive the PUSH_PROMISE, it would have to send a GET as usual.

> Therefore HTTP/2 Server Push is not desirable comparing with
> HTTP1.1+SSE

Note that the diagram above assumes HTTP/2 + SSE.  It just shows how
PUSH_PROMISE could be used with HTTP/2 + SSE.



/martin