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