Thanks for the explanations. Please see below for some comments: 2010/4/19 wangaijun <[email protected]>: > [ ... snip ... ] > > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Richard > Alimi > 发送时间: 2010年4月17日 2:26 > 收件人: wangaijun > 抄送: [email protected]; [email protected]; [email protected]; Likai; > [email protected] > 主题: Re: Is it possible to incorporate "server notification" mechanism into > current ALTO protocol > > [ ... snip ... ] > > (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.
Okay. One property of this design that I would like to point out, is that the ALTO Server may be sending notifications to clients who do not care about the particular update that was made. Of course, one advantage is simplicity and it may in fact be reasonable to make this tradeoff in some cases. > 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.). Could you be more specific here? I'm not quite sure what you mean by "not relevant to the network." > (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. I don't believe this is apparent quite yet, mostly because I'm not convinced the ALTO Server needs to keep track of this and I don't know what exactly is meant by "state change" of an ALTO Client. Do you mean application restarts? Network connectivity changes? > 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. I don't believe all ALTO Queries should be regarded as an implicit registration. This can be extremely wasteful; I believe it should be the _ALTO Client_ who decides whether or not it wishes to receive notifications. For example, if a set of ALTO Clients are using redistribution, it can be wasteful for the ALTO Server to notify all of them; the redistribution process may have its own notification mechanism. I strongly believe that explicit registration is preferred here. > (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. So, in this event, the ALTO Client would be left without notifications until it restarts? Related to this, what happens if an ALTO Server crashes? Do you envision prescribing guidelines on the storage for the notification list (take a look at NFS's requirements on stable storage to see what might be involved here if you go down this road)? If there is no stable storage for maintaining the list, I presume the ALTO Client would at least need to periodically check that it is still registered. (If it does not check periodically, you may be leaving an P2P tracker that runs for weeks or months at a time without any updated ALTO information.) Another related possibility is if the ISP decommissions one ALTO Server (or even temporarily shuts it down for maintenance); is it responsible for re-allocating "registered" clients to other ALTO Servers? > Once the ALTO server receive this query message, it will register the ALTO > Clients' contact information(ip addresses/ports pair). I presume that you mean adding at least the peer's listening port to each query message sent to the ALTO Server. > 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. With this implicit mechanism, each peer that is behind a NAT will incur a wasted notification message from the ALTO Server (unless the ALTO Client configures port-forwarding, or other adjustments for NAT traversal are made). > (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. Sure it does, unless the ALTO Server is prepared to send out at notifications to each ALTO Client that has requested information from it. Tracker-based applications are not the only P2P applications in the world. > 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. I would personally much prefer this design and it solves some of the concerns above. > 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. I guess the disagreement comes down to how much "burden" the notification is on the ALTO Server. With regards to the amount of messaging and state storage, I tend to agree that both architectures would be equivalent. However, with regards to implementation complexity, I believe that separating them can be preferred. The ALTO Server can remain as a clean design without per-client state. Notification servers have their own jobs regarding storing per-client state and failure recovery with regards to this per-client state (see above), and perhaps NAT traversal logic as well. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
