Aside from the ALTO-layer considerations, there are also protocol considerations.
If ALTO relies on HTTP, then HTTP has some limitations in this regard. There are some options: - long-polling works using pure HTTP, as long as client and server both understand that this is the desired behaviour. This is a little inefficient, but it is generally regarded as useful. - There are other protocols that might be employed, see <http://tools.ietf.org/html/draft-roach-sip-http-subscribe> --Martin > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Richard Alimi > Sent: Saturday, 17 April 2010 4:26 AM > To: wangaijun > Cc: [email protected]; [email protected]; [email protected]; Likai > Subject: Re: [alto] 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? > > (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
