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

["Thomson, Martin" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Richard Alimi
> Sent: Saturday, 17 April 2010 4:26 AM
> To: wangaijun
> Cc: [e-mail]; [e-mail]; [e-mail]; 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 <[e-mail]>:
> > 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: [phone]
> >
> > 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 <[e-mail]>
> > Subject: [alto] Interim Virtual Meeting
> > To: "[e-mail]" <[e-mail]>
> > Cc: "Vijay K. Gurbani" <[e-mail]>
> > Message-ID: <[e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/alto
> >
> >
> > End of alto Digest, Vol 18, Issue 6
> > ***********************************
> >
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto