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

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: 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, first how does establish-subscription RPC indicate server push support, how does server know server push should be used for response.
Second, SSE event and OK, PUSH-PROMISE should be established in another channel or HTTP connection?

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.
Therefore HTTP/2 Server Push is not desirable comparing with HTTP1.1+SSE

/martin