Hi Wendy and all, Please see below.
On 08/03/16 22:14, Wendy Roome wrote: > A few points: > > * The original proposal did not provide an explicit stop-updates request. > The server just pushed updates until the client closed the stream. Then > after implementing that, I discovered that it took a long time for the > server to discover that the client had closed the stream. That is why I > added stop-updates. At first that was just stop-everything; then it seemed > like a simple extension to allow the client to stop a subset of the > resources. If adding a control interface causes controversy, we could > drop stop-updates altogether. For simplicity, I agree on dropping the stop-updates. And the stream-id is also no longer needed with the removal of control interfaces. > > * Delivering push-updates for multiple resources via one stream was only > partly to minimize the number of streams. The bigger reason is that cost > maps depend on network maps, and if the network map changes, the cost map > changes as well. It is easier for the client to handle those dependencies > if the server delivers updates for all those resources via a single > stream, in a predictable order. Maybe we should make it explicit that only the cost map with its dependent network map(s) can be pushed in one stream? > > * What would a two-channel approach look like? Remember the client must > send the stop-updates request via a new TCP stream, because SSE is not > bi-directional (the client cannot sen anything after the original request > parameters). So it seems to me that it already separates control from data. Exactly. That's why I think we should make it explicit that "start-updates" is for data and "stop-updates" is for control, by separating them like the third option you proposed in the discussion with Hans. I also suggest we use "get" instead of "start" for the data channel, especially if we decide to drop "stop-updates". > * Because resources are identified by resource id, if a client wants > updates for N different ECS/EPS requests, the client must create N > different update-stream requests. Conceptually that is ugly. But if to > allow multiple ECS/EPS requests in one stream, we need a new identifier > for the specific request, which complicates the protocol. And I doubt many > clients will need that anyway. So that seemed like a premature > optimization. > > - Wendy Roome > > > >> Message: 1 >> Date: Sat, 5 Mar 2016 15:45:25 +0800 >> From: Gao Kai <[email protected]> >> To: Qiao Xiang <[email protected]>, Jensen Zhang >> <[email protected]> >> Subject: Re: [alto] State of the WG >> >> Hiall, >> >> I'd like to share some of my thoughts on the >> draft-ietf-alto-incr-update-sse. >> >> There has been a debate on the options of "start-updates" and >> "stop-updates" and Wendy has already proposed some options. I think >> since we need two channels, one for data and the other one for control, >> it is better to separate them explicitly. Basically I would vote for >> option 3 but there are still a few details I'd like to discuss. >> >> One of the reasons that "start-updates" and "stop-updates" cannot be >> mixed together is that the draft allows one stream to push updates for >> several resources. In my understanding, it is aimed to reduce the >> number of connections. However, there is a constraint that requests are >> identified only by the their resource id which is the reason why it is >> difficult to add/modify resources. >> >> Consider a system-wide ALTO client, which can have multiple ECS/EPS >> requests with different parameters. By allowing clients to label the >> requested parameters, we can provide better control functionality and >> also further reduce the number of active connections. >> >> Your thoughts and suggestions can highly appreciated. >> >> Regards, >> Kai >> >> On 29/02/16 06:26, Qiao Xiang wrote: >>> Hi All, >>> >>> The following are my comments on the draft-ietf-alto-incr-update-sse >>> draft. >>> >>> 1. The last sentence of Paragraph 4 in Sec. 2 and the last sentence in >>> Sec. 6.5 use the same example. but the first one uses "should" and the >>> second one uses "SHOULD". I suggest capitalize the first one to make >>> the draft consistent. >>> >>> 2. Section 6.6.3, "the that stream" -> "the same stream". >>> >>> 3. Section 6.9, first sentence of Paragraph 1: "a line-at-a-time" -> >>> "one line-at-a-time" seems more appropriate. >>> >>> 4. Section 6.9, second sentence of Paragraph 1: "of not tens of" -> >>> "if not tens of". >>> >>> 5. Regarding the exclusion issue of "start-updates" and >>> "stop-updates", discussed by Hans, Wendy and Jensen, I am inclined to >>> vote for Wendy's option 3, i.e., using two separate request >>> "start-new-update-stream" and "modify-existing-update-stream". >>> >>> I will post to the group if I have any other comments. Thanks. >>> >>> >>> >>> Best >>> Qiao >>> > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto Regards, Kai
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
