Hi,Alimi,
Thanks for your comments, please see the reply inline below. Wang Aijun Network Infrastructure Research Division Network and Service Research Department China Telecom Coporation Beijing Research Institute -----邮件原件----- 发件人: richard.al...@gmail.com [mailto:richard.al...@gmail.com] 代表 Richard Alimi 发送时间: 2010年4月17日 2:26 收件人: wangaijun 抄送: alto@ietf.org; su...@ctbri.com.cn; zho...@ctbri.com.cn; Likai; wangq...@ctbri.com.cn 主题: Re: Is it possible to incorporate "server notification" mechanism into current ALTO protocol I believe that this is now a question for the WG (since it is a WG document), and should receive comments from more WG participants than just one of the draft's editors. However, I can give my personal opinions (my initial thoughts at least) on that may need further consideration before being incorporated. I don't mean to imply that _if_ something were to be included we must have all of the details worked out, but we should be reasonably comfortable with the scope of such a mechanism. (1) For what entities can an ALTO Client register for notifications? Network map changes? Cost map changes? Changes to only a subset of the maps (e.g., as returned by the Map Filtering Service)? Endpoint properties? Endpoint costs? How specific or general do you envision this notification mechanism to be? Reply: Generally, any change of network condition/policy can lead the update of cost map or network map， so it is appropriate to design the notification mechanism as one for general purpose, that is to say, any change in network condition will trigger the server notification message. Once the ALTO clients receive this notification message, they can get their specific interesting ALTO information via the current ALTO query/response message, with the help of Map Filtering Service. For information about Endpoint costs and Endpoint properties, we think they should be dealt by p2p tracker or p2p application themselves, the ISP should not consider these things because they are not relevant to the network(there are also a lot discussion about the appropriate usage of these information, whether it is beneficial or not has not been decided yet.). (2) How "persistent" is the registration for notifications? Does an ALTO Client simply register for the _next_ network event, and is expected to re-register after receiving this particular notification? Or, does an ALTO Client register for notifications for all future network events (in which case, a mechanism for un-registering must also be provided)? Reply: It is apparently that the ALTO server should aware the state change of registered ALTO clients. The re-reigster process as you described is more appropriate. But according to our current draft, it is unnecessarily to redesign the re-register message: when the ALTO server send one notification, it is expected the ALTO client will send one query message immediately or in short time(this time can be configured). This query message can be treated as one re-register message. If the server does not receive any message from the listed ALTO Clients, then it will be deleted from the register table in ALTO Server. (3) What happens if the ALTO Server cannot reach a particular client that registered for notifications -- is it permanently removed from the notification list? What if there is a network failure between the ALTO Server and ALTO Client - is the ALTO Client expected to somehow detect this and re-register for notifications? Reply: When the ALTO Clients startup, it will first query the ALTO server. Once the ALTO server receive this query message, it will register the ALTO Clients’ contact information(ip addresses/ports pair). If the ALTO server does not receive the new query message after its notification message, the ALTO client will be removed from the notification list. The client can re-activated the register/notification process by sending the query message in any time. (4) I see in the draft that you mention "In order to improve the ALTO server's efficiency, only P2P tracker and application server will be notified by ALTO server." How do does the ALTO Server know which ALTO Clients are P2P trackers or application servers? Is there a whitelist maintained by the ALTO Service's provider? Reply: Here the application server is mainly referred other Client/Server style application, in which the application server can notify its client for the change of network information. The ALTO server need not distinguish the differences between them. You also mention below that "For tracker-less application, if one PID head was elected as described in draft http://tools.ietf.org/id/draft-ikpark-alto-virtual-p2ptracker-00.txt the notification mechanism can also applied to it." Looking back at this draft, I think you are assuming that the ALTO Server maintains state information about the particular P2P swarms -- this would require a radical shift from the current direction of the ALTO Protocol and the multiple solution proposals that fed into it. My personal preference would be to keep P2P swarm information out of the ALTO Server; an alternative method for the P2P application would be to utilize a different mechanism such as a DHT. Reply: Currently, our draft is mainly for tracker-based p2p application. It is more complex in tracker-less environment because the ALTO clients that are embedded in p2p clients are very unstable. One alternative solution except the above proposal is that let the ALTO clients/p2p clients decide whether they need the notification or not themselves. If it is true(for some stable p2p peer), they can register directly to the ALTO server, or else just use the traditional query/response mechanism. Another architecture for providing notifications (if they are needed in only certain deployment scenarios) is to define it as a separate protocol. "Notification servers" could be deployed separately (either physically or logically separate) from the ALTO Servers. Notification servers could be responsible for performing more frequently polling the ALTO Server to look for changes, and a notification mechanism can operate between the Notification Servers and ALTO Clients. The same protocol could even be used between Notification Servers, and be used for distributing notifications in a distribution-tree-like fashion. Of course, this would not provide "realtime" notifications (in the sense that it still operates as a polling mechanism), but I just mention it as another possibility for consideration that might satisfy your particular design goals. Reply: This architecture has the same pros and cons of our embed solution. The current notification mechanism will not lay much extra burden to the ALTO server, the notification protocol between ALTO servers and distribution-tree-like fashion can still be designed accordingly, because in realty, the network information will come authoritatively from one administration point for one ISP and the ALTO servers will be deployed in distributed in future. Thanks, -- Richard Alimi Department of Computer Science Yale University 2010/4/16 wangaijun <wangai...@tsinghua.org.cn>: > Hi Alimi, > > We have discussed about our > draft(http://tools.ietf.org/id/draft-sun-alto-notification-00.txt) for short > time in IETF meeting in Anaheim. It a pity we did not get the chance to > illustrate the prepared ppt(see attached file)in this meeting. > > After this meeting, I discussed your comments with my colleagues, and we > still think the "server notification" mechanism should be incorporated into > the current ALTO protocol. It may act as one optional implementation, and > mainly aim at the tracker-based environment. For tracker-less application, > if one PID head was elected as described in draft > http://tools.ietf.org/id/draft-ikpark-alto-virtual-p2ptracker-00.txt, > the notification mechanism can also applied to it, on the assumption that it > has the public IP address. These implementation can certainly reduce the > burden of the ALTO server and let the ALTO clients get the ALTO information > timely. This eventually will let the p2p traffic to keep up with the > adjustment pace of ISP's policy. > > Wait for you and other interested persons' comments. If possible, we can > discuss it in the coming " Interim Virtual Meeting " or next IETF plenary > meeting. > > Best regards. > > 王爱俊 > 网络业务研究部 基础网络研究室 > 中国电信 北京研究院 > Tel: 010-58552347 > > Wang Aijun > Network Infrastructure Research Division > Network and Service Research Department > China Telecom Coporation Beijing Research Institute > > > > > Today's Topics: > > 1. Interim Virtual Meeting (Enrico Marocco) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 15 Apr 2010 15:36:11 +0200 > From: Enrico Marocco <enrico.maro...@telecomitalia.it> > Subject: [alto] Interim Virtual Meeting > To: "alto@ietf.org" <alto@ietf.org> > Cc: "Vijay K. Gurbani" <v...@alcatel-lucent.com> > Message-ID: <4bc7164b.2080...@telecomitalia.it> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > > as mentioned during the last meeting, we plan to have an interim WebEx > meeting between Anaheim and Maastricht. The date we have identified is > June 16, but it may still be subject to change. > > In particular, we would like to focus the meeting on progressing the > work on the protocol document, info redistribution, deployment > considerations and v4/v6 issues. If anyone would like to propose other > topics, please check well in advance with the chairs. > > An official email from the IETF secretariat will follow in the following > weeks. > > -- > Ciao, > Enrico > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/x-pkcs7-signature > Size: 5162 bytes > Desc: S/MIME Cryptographic Signature > Url : > <http://www.ietf.org/mail-archive/web/alto/attachments/20100415/18b44c56/att > achment.bin> > > ------------------------------ > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > > > End of alto Digest, Vol 18, Issue 6 > *********************************** >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
