I agree. As I said, I certainly see value in the proposed mechanism, but there are details to be filled and that can continue in parallel.
Thanks, Reinaldo On 4/16/10 11:26 AM, "Richard Alimi" <[email protected]> wrote: > 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
