Hi, Alimi: We will revise and update our current draft to reflect the consensus acquired via the discussion in these days. We are very appropriated for your valuable advices in previous consecutive e-mails. We proposed the refined version of our draft can be incorporated into the later version of ALTO protocol.
Comments from other interested persons are also welcomed. Thanks in advance. Wang Aijun Network Infrastructure Research Division Network and Service Research Department China Telecom Coporation Beijing Research Institute -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Richard Alimi 发送时间: 2010年4月20日 23:32 收件人: wangaijun 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Likai 主题: Re: 答复: 答复: Is it possible to incorporate "server notification" mechanism into current ALTO protocol Hi Aijun, 2010/4/20 wangaijun <[email protected]>: > Hi,Alimi: > > The situation seems more complex than our initial purpose, we should make > some clarification in order to make the progress step a little further. Yes - things like this can quickly become complex when you start to consider the details. Explicitly specifying the scope and what kind of guarantees are provided or not provided can be very important towards reducing the complexity. > 1. Current "server notification" is mainly aim to increase the > efficiency of ALTO service for tracker-based environment. We should pay more > attention to this than the trackless ones because we observed that the > predominant p2p traffic in our network is tracker-based. Under the condition > of spending same efforts, we can get more valuable results on these > controllable p2p traffic than the more diverse, trackless type p2p traffic. I think this is a reasonable goal; my only question below was how the ALTO Server can tell the difference between an ALTO Client running at a tracker, and an ALTO Client running at a P2P client. One possibility is a whitelist (P2P trackers need to tell the ALTO service provider out-of-band). Another possibility is that the ALTO Server doesn't know the difference and is prepared to send notifications to any ALTO Client that wishes to receive them (I don't think this is a good idea). Regardless, I think there should be some indication (e.g., error message) from the ALTO Server that it is not willing to provide notifications to particular ALTO Clients. > 2. The following consideration will focus only tracker-based situation, > trackless situation will be took into account in future after we can > seek/find one more efficient algorithm for information distribution. If we > can find such algorithm, the notification mechanism can function together > with it to increase the ALTO service efficiency in trackless environment. I think it is fine to focus on tracker-based first. However, you cannot ignore the existence of tracker-less ALTO Clients. Put another way, the ALTO Server must not roll over and die if deployed in a network with many non-trackers querying for ALTO information. I think your comments below begin to address this. > 3. For tracker-based situation, there will be one table in ALTO server > to record the IP address/port of p2p tracker, to which the ALTO server will > send the notification message. This table will be formed by manual under the > cooperation contracts between ISP and these p2p application developers. This > table will be "half-persistent" in the sense that one member will be > deactivated if the ALTO sever does not receive any query messages during > three query interval periods. How long is a query interval period? How does the ALTO Client know how often it should query to keep itself registered? > It will be activated again immediately once > the ALTO server receives its query message, for example, when the tracker > startup or the break path to the ALTO server is recovered. Okay, thank you for the clarification. I think this is more reasonable than what is discussed in the draft. Manual configuration is an option, but there might be a way to automatically register for notifications in the future as well. > 4. For tracker-based situation, the notification mechanism can be > designed more specific, as you have advised. We can modify our current > notification message to include the information that point out which parts > of ALTO map has been changed. The interested ALTO client can then send the > query message to ALTO server to get the updated ALTO information, other ALTO > clients can neglect this notification message then. It can also includes the > change of endpoints' cost and properties. I did not mean that this _needed_ to be done. It was meant as a question about how flexible you envisioned the mechanism to be (instead of a recommendation). If the initial target is P2P trackers, I suspect that simply notifying that the Network Map and default Cost Map has changed is sufficient for now. From the standards point of view, it would be nice of the protocol is extensible enough that allows a more fine-grained notifications in the future, even if they are not explicitly specified at this time. > 5. For tracker-based situation, the ALTO sever will be deployed in > distribute. Every ALTO server will record only the registered ALTO > clients(p2p trackers) within its zone. The ALTO servers in one zone should > be deployed in redundancy, this will keep the ALTO service uninterrupted > when one of them is maintained or decommissioned. Right - but my question is what do you do with the existing registrations. Are you assuming that the registration list is replicated between each ALTO Server in a "zone"? Is the "zone" in your model is determined by the manual registration process? Note that the Discovery process probably may some impact here as well. Given the soft-state design you discussed above, perhaps you don't need to do such replication if failures or decomissioning are rare events. However, if load-balancing is used, you may need to have some considerations for shared state between ALTO Servers. My only comment here is that it should be mentioned in the document explicitly what level of guarantees are provided. Knowing the guarantees would be extremely important in writing an ALTO Client making use of such a notification mechanism. > 6. For tracker-based situation, there is little necessary to introduce > one new Notification server into current ALTO architecture. There will exist > very small amounts of messages/burden aroused from the notification > mechanism. As I mentioned, the concern was not with regards to messaging or the amount of storage regarding client state. The concern was implementation complexity. Thanks! -- Richard Alimi Department of Computer Science Yale University > Best Regards. > > > Wang Aijun > Network Infrastructure Research Division > Network and Service Research Department > China Telecom Coporation Beijing Research Institute > > > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Richard Alimi > 发送时间: 2010年4月20日 2:46 > 收件人: wangaijun > 抄送: [email protected]; [email protected]; [email protected]; > [email protected]; Likai > 主题: Re: 答复: Is it possible to incorporate "server notification" > mechanism into current ALTO protocol > > 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
