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

["Y. Richard Yang" <[e-mail]>]

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]> 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?



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

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]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================