Hi Richard,
Thank you for your suggestions and comments. Plz see the replies inline. BTW. I have just uploaded a revised version of this draft. http://www.ietf.org/id/draft-deng-alto-p2pcache-02.txt Further comments are welcome. BR Lingli 发件人: yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] 代表 Y. Richard Yang 发送时间: 2013年7月28日 6:21 收件人: 邓灵莉/Lingli Deng 抄送: alto@ietf.org 主题: Re: [alto] 转发: New Version Notification for draft-deng-alto-p2pcache-00.txt Hi Lingli, A very interesting document, and the idea of using cache locations and types to compute network map and cost map is novel. Here are some early comments: - page 1 Abstract: it can be helpful to add a sentence or two on the terms "forward caching" and "transparent caching", as they are not complex concepts, but many readers may not always remember their definitions. [dll] You are right. I added a new “terminology” section to the updated draft. - page 1: DIPs are typos of PIDs? [dll] I am afraid to say yes. Sorry for the confusion. Thank you for pointing it out. - page 2: 80% traffic is P2P in China Mobile WLANs?! Do you have a more detailed breakdown which you can share? This can help with our understanding of the problem. [dll] I am sorry to say I don’t have the first-handed data at hand. I will get contact with my colleagues and see if we may have a more informative description about this problem. - page 3: "characteristics of the DCF model in 802.11 ... downlink congestion" It is not clear to me which DCF properties are at play here. For ChinaMobile public WLANs, both downlink and uplink are scheduled by DCF? [dll] There is basic indication under the current DCF model, that in order to achieve fairness among mobile stations, in the long run, each stations has a equal chance of getting the wireless slot given they all have a sustainable long traffic to send. In other words, there is an implicit unfairness between uplink and downlink traffic under the BSS model, where the AP holds the throat of all the downlink traffic and competing with the uplink traffic from potentially a large group of other user mobile devices. -page 3: "at AC": AC is introduced later in the document. It can be helpful to define it first before use. [dll] Thank you for the suggestion. It’s been added into the new “terminology” section in the updated draft. - page 3: "suboptimal to use network type as dividers for different PIDs..." Can you please elaborate some more here on why suboptimal? Is it consistent with the rest? [dll] It is referring to the recommendations provided by the deployment draft in terms of wireless scenarios. By suboptimal, I mean if we consider the effect of caches in the domain, we would see that their existence do have an impact to cost between nodes in the same PID. But if we stick to using network types as dividers for PIDs, there is no chance that cost map would ever grasp this kind of information. - page 5/Sec. 3.2-3.3 It seems that you may use the general Distributed System/BSS/ESS concept of 802.11. Does it help to use the terms of 802.11? Your architecture appears to extend beyond different types of networks, [dll] Yes, the reverse/bidirectional caches are proposed for 802.11 networks, but it seems to me that similar problem may exist in other networks, as long as there’s layers of caches deployed. - page 7/Sec. 4.1: "other local peers outside ..." Remove local? My understanding is that the details of Sec. 4.1 are important for others to understand your messages; hence, will it be better if you elaborate a bit on the process. [dll] Yes, it’s confusing here. What I meant to say is “other peers outside AN1 but within ISP2”. Changes have been made to the updated draft to clarify this. In more details, is it possible to derive a quantitive model to compute normalized cost maps, based on location of caches, as you mentioned, as well as cache hit rations? [dll] That’s a bit of implementation question to me concerning how to compute a reasonable cost map, with considerations of local caching facilities. But yes, why not? Just some initial comments. Thanks! Richard On Thursday, July 4, 2013, 邓灵莉/Lingli Deng wrote: Hi all, We have just submitted a draft proposing to take considerations on the locations of operator-deployed P2Pcaches in the formation of network topology abstraction. http://www.ietf.org/internet-drafts/draft-deng-alto-p2pcache-00.txt Your comments are welcome. Thank you~ BR Lingli -----邮件原件----- 发件人: internet-dra...@ietf.org <javascript:;> [mailto:internet-dra...@ietf.org <javascript:;> ] 发送时间: 2013年7月4日 12:00 收件人: Deng Lingli; Lingli Deng; Yan Zhang 主题: New Version Notification for draft-deng-alto-p2pcache-00.txt A new version of I-D, draft-deng-alto-p2pcache-00.txt has been successfully submitted by Lingli Deng and posted to the IETF repository. Filename: draft-deng-alto-p2pcache Revision: 00 Title: Considerations for ALTO with network-deployed P2P caches-00 Creation date: 2013-07-04 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-deng-alto-p2pcache-00.txt Status: http://datatracker.ietf.org/doc/draft-deng-alto-p2pcache Htmlized: http://tools.ietf.org/html/draft-deng-alto-p2pcache-00 Abstract: Transparent forwarding caching effectively localizes the downloading P2P traffic within the sub-net under its coverage resulting in reduction of network cost for cross-boundary peer selection, whereas transparent reverse caching blocks the uploading traffic outside a wireless sub-net leading to elimination of network cost for wireless uploading peer selection. In other words, caching between pairs of endpoints changes the traffic cost along the way. Therefore, it is proposed to use locations of caches as dividers of different DIPs to guide intra-ISP network abstraction and mark costs among them according to the location and type of relevant caches. The IETF Secretariat _______________________________________________ alto mailing list alto@ietf.org <javascript:;> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
