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? (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)? (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? (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? 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. 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. Thanks, -- Richard Alimi Department of Computer Science Yale University 2010/4/16 wangaijun <[email protected]>: > 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 <[email protected]> > Subject: [alto] Interim Virtual Meeting > To: "[email protected]" <[email protected]> > Cc: "Vijay K. Gurbani" <[email protected]> > Message-ID: <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto > > > End of alto Digest, Vol 18, Issue 6 > *********************************** > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
