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

[xin wang <[e-mail]>]

Dear Richard,


Thanks for the reply. Please see the comment below:



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 <[e-mail]<mailto:[e-mail]>> wrote:

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.

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?

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



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?).

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




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




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