Re: [alto] ***SPAM*** 10.657 (5) Re: 答复: Is it possible to incorporate "server notification" mechanism into current ALTO protocol

["Y.J. GU" <[e-mail]>]

And you may also want to consider how the notification mechanism can be applied in ALTO redistribution. I believe that will be an interesting topic. 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard
> Alimi
> Sent: Thursday, June 10, 2010 11:03 PM
> To: wangaijun
> Cc: [e-mail]; [e-mail]; Likai; [e-mail];
> [e-mail]
> Subject: [alto] ***SPAM*** 10.657 (5) Re: 答复: Is it possible to incorporate "server
> notification" mechanism into current ALTO protocol
> 
> Hi Aijun,
> 
> 2010/5/20 wangaijun <[e-mail]>:
> > Hi Alimi,Penno and other interested ALTO fellows
> >
> > We have submitted the updated version of our draft about notification
> > mechanism at http://tools.ietf.org/id/draft-sun-alto-notification-02.txt,
> > any comments are welcomed.
> 
> I think the major concerns with the previous draft were addressed.
> Using an out-of-band registration mechanism is one possibility, but I
> know that there were comments from others regarding other
> possibilities as well.  For example, one could ask ALTO Clients to
> maintain a persistent connection with the ALTO Server, over which the
> ALTO Server could simply push map updates when available.  While such
> a mechanism may not be appropriate for P2P, it may be appropriate for
> a CDN scenario.
> 
> These are probably perfect topics for discussion during the interim meeting.
> 
> >
> > Is it necessary or possible to make a poll for this mechanism to be
> > incorporated into the current ALTO protocol?
> 
> As far as "necessary", I would say yes -- as far as possible, I don't
> know at this point :)
> 
> It seems the notification mechanism is decoupled enough (and not
> necessary for basic operation) so my personal feeling is that it would
> be best to keep as a separate draft.  In particular, there is still
> room for it to evolve -- see comments above about other possibilities
> to explore. This would allow you to maintain some "ownership" for it
> as it is being revised, as opposed to shifting to the editors of the
> protocol document at a preliminary stage.  Depending on what happens
> with the protocol document itself (the possibility of splitting it up
> was mentioned at one meeting), such extensions may even be separate
> documents in the future anyways.
> 
> Of course, this is just my personal opinion and input from the WG is welcomed.
> 
> Rich
> 
> >
> > Best Regards.
> >
> >
> > Wang Aijun
> > Network Infrastructure Research Division
> > Network and Service Research Department
> > China Telecom Coporation Beijing Research Institute
> >
> >
> > -----邮件原件-----
> > 发件人: wangaijun [mailto:[e-mail]]
> > 发送时间: 2010年4月21日 20:24
> > 收件人: 'Richard Alimi'
> > 抄送: '[e-mail]'; '[e-mail]'; '[e-mail]';
> > '[e-mail]'; '[e-mail]'; 'Likai'
> > 主题: Re: Is it possible to incorporate "server notification" mechanism into
> > current ALTO protocol
> >
> > 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
> >
> >
> > -----邮件原件-----
> > 发件人: [e-mail] [mailto:[e-mail]] 代表
> > Richard Alimi
> > 发送时间: 2010年4月20日 23:32
> > 收件人: wangaijun
> > 抄送: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; Likai
> > 主题: Re: 答复: 答复: Is it possible to incorporate "server notification"
> > mechanism into current ALTO protocol
> >
> > Hi Aijun,
> >
> > 2010/4/20 wangaijun <[e-mail]>:
> >> 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
> >>
> >>
> >> -----邮件原件-----
> >> 发件人: [e-mail] [mailto:[e-mail]] 代表
> >> Richard Alimi
> >> 发送时间: 2010年4月20日 2:46
> >> 收件人: wangaijun
> >> 抄送: [e-mail]; [e-mail]; [e-mail];
> >> [e-mail]; 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 <[e-mail]>:
> >>> [ ... snip ... ]
> >>>
> >>> -----邮件原件-----
> >>> 发件人: [e-mail] [mailto:[e-mail]] 代表
> >> Richard
> >>> Alimi
> >>> 发送时间: 2010年4月17日 2:26
> >>> 收件人: wangaijun
> >>> 抄送: [e-mail]; [e-mail]; [e-mail]; Likai;
> >>> [e-mail]
> >>> 主题: 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto