Subject: Re: [alto] Is it possible to incorporate "server notification" mechanism into current ALTO protocol

From: Richard Alimi <[email-masked]>
Date: Fri, 16 Apr 2010 14:26:28 -0400

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-masked]>:
> 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-masked]>
> Subject: [alto] Interim Virtual Meeting
> To: "[email-masked]" <[email-masked]>
> Cc: "Vijay K. Gurbani" <[email-masked]>
> Message-ID: <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>
> End of alto Digest, Vol 18, Issue 6
> ***********************************
>

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 16 Apr 2010 14:50:35 -0400

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

> 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

(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

(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

You
> also mention below that "For tracker-less application, if one PID
head was
> elected as described in
> draft
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

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
mention
> it as another possibility for consideration that might satisfy
your particular
> design goals.

Thanks,
Yale
> University

2010/4/16 wangaijun <[email-masked]>:
> 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
> 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.
>
> 网络业务研究部 基础网络研究
> 室
> Today's
> Topics:
> 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
________________________________________
> _______
alto mailing
> list
[email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 19 Apr 2010 07:33:12 +0800

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-masked] [mailto:[email-masked]] On Behalf Of
> Richard Alimi
> Sent: Saturday, 17 April 2010 4:26 AM
> To: wangaijun
> Cc: [email-masked]; [email-masked]; [email-masked]; Likai
> Subject: Re: [alto] Is it possible to incorporate "server notification"
> mechanism into current ALTO protocol
> 
> > <http://www.ietf.org/mail-
> archive/web/alto/attachments/20100415/18b44c56/att
> > achment.bin>
> >

---

From: Richard Alimi <[email-masked]>
Date: Mon, 19 Apr 2010 14:45:54 -0400

Thanks for the explanations.  Please see below for some comments:

2010/4/19 wangaijun <[email-masked]>:
> [ ... snip ... ]
>
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Richard
> Alimi
> 发送时间: 2010年4月17日 2:26
> 收件人: wangaijun
> 抄送: [email-masked]; [email-masked]; [email-masked]; Likai;
> [email-masked]
> 主题: Re: Is it possible to incorporate "server notification" mechanism into
> current ALTO protocol
>
> [ ... snip ... ]
>
> 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."

> 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.

> 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).

> 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.

> 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.

> 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.