Subject: [alto] Some comments on draft-ietf-alto-incr-update-sse-07

From: xin wang <[email-masked]>
Date: Thu, 20 Jul 2017 03:14:31 +0000

Dear authors of ALTO Incremental Updates Using Server-Sent Events (SSE),

The draft about incremental updates by using Server-Sent Events (SSE) proposes a general framework for incremental updates of network information. The concept of update stream resource in the framework allows a unified interface to ALTO clients. The interface not only considers GET-mode ALTO services but also POST-mode services, which should support most future extensions of ALTO services. The following is my comments:

a. The benefits of the general framework

Besides of the extension-friendly design, I am thinking of other benefits of bringing all ALTO services together by using a new update stream resource. First, let me propose an alternative simple solution of incremental updates. The solution views each subscription independently, which means that each time a client calls an ALTO service (e.g., get network-map) to get incremental updating data, the server will establish a connection for the data. Then, by comparing with the simple solution, we can find an obvious benefit of the solution in the draft should be reducing redundant connections. Also, another benefit would be that it makes removing resources very easily. Though SSE itself supports disconnection API, it will add new APIs to the simple solution. Moreover, because one connection could manage multiple resources which may have overlapping (also dependencies) between each other, I am considering whether there exists an efficient way to make scheduling for updating these resources.

b. Full replacement or incremental updates

In the client side, if the data is updated in incremental ways, then there should be some algorithms to apply the updates like the algorithm in Section 4.2.1. However, if the data allows full replacement, then the client can easily replace the data with the new one instead of applying the algorithms. Also, the “incremental-updates” field is “true” indicates the server MAY send incremental update events, which means that the client may receive either a full replacement or incremental updates in each time (is this right?). My idea is that if the response from the server can indicate whether this update is a full replacement or incremental one, the client should benefit from that.

Also, there are some typos may be fixed:

Page 10: "we now gives" -> "we now give";

Page 13: missing “)” in "(see Section 6.3.”;

Best,

X.Tony Wang

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 20 Jul 2017 11:10:55 +0200

Dear Tony,

Thanks a lot for the review. Please see below for a quick response.

On Thu, Jul 20, 2017 at 5:14 AM, xin wang <[email-masked]> wrote:

> The draft about incremental updates by using Server-Sent Events (SSE)
> proposes a general framework for incremental updates of network
> information. The concept of update stream resource in the framework allows
> a unified interface to ALTO clients. The interface not only considers
> GET-mode ALTO services but also POST-mode services, which should support
> most future extensions of ALTO services. The following is my comments:
>
>
> Besides of the extension-friendly design, I am thinking of other benefits
> of bringing all ALTO services together by using a new update stream
> resource.
>

This is an interesting view: using an update stream resource to bring all
ALTO resources together.

> First, let me propose an alternative simple solution of incremental
> updates. The solution views each subscription independently, which means
> that each time a client calls an ALTO service (e.g., get network-map) to
> get incremental updating data, the server will establish a connection for
> the data. Then, by comparing with the simple solution, we can find an
> obvious benefit of the solution in the draft should be reducing redundant
> connections. Also, another benefit would be that it makes removing
> resources very easily. Though SSE itself supports disconnection API, it
> will add new APIs to the simple solution. Moreover, because one connection
> could manage multiple resources which may have overlapping (also
> dependencies) between each other, I am considering whether there exists an
> efficient way to make scheduling for updating these resources.
>
>
>
The current draft has some dependency/consistency requirements:
- Sec. 7.6.2: Event sequence requirements, on updates of dependent resources
- Sec. 7.6.3 Cross-stream consistency requirements
- Sec. 10: Client processing when there are dependencies

My understanding is that you are suggesting a subsection (or two
subsections) on
- IRD announcement, and one
- subscription
consistency

Do I understand you correctly?

> In the client side, if the data is updated in incremental ways, then there
> should be some algorithms to apply the updates like the algorithm in
> Section 4.2.1. However, if the data allows full replacement, then the
> client can easily replace the data with the new one instead of applying the
> algorithms. Also, the “incremental-updates” field is “true” indicates the
> server MAY send incremental update events, which means that the client may
> receive either a full replacement or incremental updates in each time (is
> this right?).
>

Yes.

> My idea is that if the response from the server can indicate whether this
> update is a full replacement or incremental one, the client should benefit
> from that.
>

I believe that the media type in the "event" field can indicate whether
this is a full or incremental (if so, which diff method). Does this address
your issue or you are suggesting a more general solution?

Thanks!
Richard

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: xin wang <[email-masked]>
Date: Thu, 20 Jul 2017 17:54:53 +0000

Dear Richard,

Thanks for the reply. Please see the comment below:

Dear Tony,

On Thu, Jul 20, 2017 at 5:14 AM, xin wang <[email-masked]<mailto:[email-masked]>> wrote:

Besides of the extension-friendly design, I am thinking of other benefits of bringing all ALTO services together by using a new update stream resource.

This is an interesting view: using an update stream resource to bring all ALTO resources together.

First, let me propose an alternative simple solution of incremental updates. The solution views each subscription independently, which means that each time a client calls an ALTO service (e.g., get network-map) to get incremental updating data, the server will establish a connection for the data. Then, by comparing with the simple solution, we can find an obvious benefit of the solution in the draft should be reducing redundant connections. Also, another benefit would be that it makes removing resources very easily. Though SSE itself supports disconnection API, it will add new APIs to the simple solution. Moreover, because one connection could manage multiple resources which may have overlapping (also dependencies) between each other, I am considering whether there exists an efficient way to make scheduling for updating these resources.

My understanding is that you are suggesting a subsection (or two subsections) on
- IRD announcement, and one
- subscription
consistency

>> I am suggesting to add a subsection to summarize the benefits of the proposed solution based on the requirements for the incremental updates or add some discussions to discuss how the proposed solution derived from the problem. Because people might quickly come up with their own solutions (like the simple one above) for the problem and they may want to know why yours is better.

In the client side, if the data is updated in incremental ways, then there should be some algorithms to apply the updates like the algorithm in Section 4.2.1. However, if the data allows full replacement, then the client can easily replace the data with the new one instead of applying the algorithms. Also, the “incremental-updates” field is “true” indicates the server MAY send incremental update events, which means that the client may receive either a full replacement or incremental updates in each time (is this right?).

Yes.

My idea is that if the response from the server can indicate whether this update is a full replacement or incremental one, the client should benefit from that.

I believe that the media type in the "event" field can indicate whether this is a full or incremental (if so, which diff method). Does this address your issue or you are suggesting a more general solution?

>> Yes. This solves the issue.

Best,
X.Tony Wang

Thanks!
Richard

Best,

X.Tony Wang

--
--
 =====================================
| Y. Richard Yang <[email-masked]<mailto:[email-masked]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Lyle Bertz <[email-masked]>
Date: Mon, 24 Jul 2017 12:49:22 -0500

All,

I asked during the meeting about whether or not it made sense to look at
alternatives to W3C SSE.  However, in subsequent WG meetings such as
netconf use of W3C SSE is the norm and the right way to go.

tl;dr - don't change the draft - keep the use of W3C SSE.

Lyle

On Wed, Jul 19, 2017 at 10:14 PM, xin wang <[email-masked]> wrote:

> resource. First, let me propose an alternative simple solution of
> incremental updates. The solution views each subscription independently,
> which means that each time a client calls an ALTO service (e.g., get
> network-map) to get incremental updating data, the server will establish a
> connection for the data. Then, by comparing with the simple solution, we
> can find an obvious benefit of the solution in the draft should be reducing
> redundant connections. Also, another benefit would be that it makes
> removing resources very easily. Though SSE itself supports disconnection
> API, it will add new APIs to the simple solution. Moreover, because one
> connection could manage multiple resources which may have overlapping (also
> this right?). My idea is that if the response from the server can indicate
> whether this update is a full replacement or incremental one, the client
> should benefit from that.
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 24 Jul 2017 15:52:40 -0500

Lyle, all: Correct; I believe W3C SSE is the right choice here.

Many moons ago, when we were all very young (okay, ~3.5 years ago, but
we were still younger), there were other contenders; websockets comes to
mind [1].  But as the work progressed, it made sense to stick with W3C
SSE.

Cheers,

[1] https://tools.ietf.org/html/draft-marocco-alto-ws-02

On 07/24/2017 12:49 PM, Lyle Bertz wrote:
> On Wed, Jul 19, 2017 at 10:14 PM, xin wang <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     The draft about incremental updates by using Server-Sent Events
>     (SSE) proposes a general framework for incremental updates of
>     network information. The concept of update stream resource in the
>     framework allows a unified interface to ALTO clients. The interface
>     not only considers GET-mode ALTO services but also POST-mode
>     services, which should support most future extensions of ALTO
>     services. The following is my comments:
> 
> 
>     Besides of the extension-friendly design, I am thinking of other
>     benefits of bringing all ALTO services together by using a new
>     update stream resource. First, let me propose an alternative simple
>     solution of incremental updates. The solution views each
>     subscription independently, which means that each time a client
>     calls an ALTO service (e.g., get network-map) to get incremental
>     updating data, the server will establish a connection for the data.
>     Then, by comparing with the simple solution, we can find an obvious
>     benefit of the solution in the draft should be reducing redundant
>     resources very easily. Though SSE itself supports disconnection API,
>     it will add new APIs to the simple solution. Moreover, because one
>     connection could manage multiple resources which may have
>     overlapping (also dependencies) between each other, I am considering
>     whether there exists an efficient way to make scheduling for
>     updating these resources.
> 
> 
>     In the client side, if the data is updated in incremental ways, then
>     there should be some algorithms to apply the updates like the
>     algorithm in Section 4.2.1. However, if the data allows full
>     replacement, then the client can easily replace the data with the
>     new one instead of applying the algorithms. Also, the
>     “incremental-updates” field is “true” indicates the server MAY send
>     incremental update events, which means that the client may receive
>     either a full replacement or incremental updates in each time (is
>     this right?). My idea is that if the response from the server can
>     indicate whether this update is a full replacement or incremental
>     one, the client should benefit from that.
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/alto>
> 
> 
> 
> 

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
Email: [email-masked] / [email-masked]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 25 Jul 2017 17:08:32 -0400

Dear Lyle, all,

Thanks a lot for the feedback. We will then continue to push the work
forward as soon as we can.

Richard