Hi all,
I would prefer to one TCP stream not two ones. Adding more communication TCP streams is just a burden for an ALTO server because all the control and data message are application processed. BR G.Robert Chen ------------------------------------------------------------------------------------------------------------------------------------- G.Robert Chen (Chen Guohai 陈国海). Network Research Department, Huawei Technologies Co., Ltd. Telephone: 0086-25-56624606; http://www.huawei.com ------------------------------------------------------------------------------------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ---------------------------------------------------------------------------------------------------------------------------------------- -----Original Message----- From: alto [mailto:[email protected]] On Behalf Of Wendy Roome Sent: Tuesday, March 08, 2016 10:15 PM To: [email protected] Subject: Re: [alto] State of the WG 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
