Subject: [alto] FW: I-D Action:draft-kiesel-alto-3pdisc-03.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 13 Jul 2010 10:39:26 +0200

Hi,

Here is an updated draft of the "Third-party ALTO server discovery".

However, despite the title still saying "Third-party ALTO server discovery", we have updated the draft so that the discovery mechanism covers **all** cases. The title of the draft will be changed with the next revision of it.

The discovery mechanism uses the DNS Service Resource Records (SRV RR) to discover ALTO servers.

Let me know your comments

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, July 09, 2010 6:15 PM
> To: [email-masked]
> Subject: I-D Action:draft-kiesel-alto-3pdisc-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : Third-party ALTO server discovery
> 	Author(s)       : S. Kiesel, et al.
> 	Filename        : draft-kiesel-alto-3pdisc-03.txt
> 	Pages           : 18
> 	Date            : 2010-07-09
> 
> The goal of Application-Layer Traffic Optimization (ALTO) is to
> provide guidance to applications, which have to select one or several
> hosts from a set of candidates that are able to provide a desired
> resource.
> 
> Entities seeking guidance need to discover and possibly select an
> ALTO server to ask.  This is called ALTO server discovery.  This memo
> describes an ALTO server discovery mechanism based on DNS SRV
> records.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kiesel-alto-3pdisc-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 22 Jul 2010 09:47:50 +0300

Hi,
I reviewed the draft and noticed the change. There is a similar work on
general discovery in draft-song-alto-server-discovery-02. This draft was
discussed in previous meeting and one of the comments was to use DHCP for
discovering the local domain as also discussed in
http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-15.

I saw in the 3pdisc draft the limitation you gave on DHCP and I am not sure
I understand the last two bullets. The last bullet is the same problem as
for the DNS case and requires the ALTO client to provide the domain name to
the tracker. As for the bullet before last, look at the geopriv document.

Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Stiemerling
> Sent: Tuesday, July 13, 2010 11:39 AM
> To: [email-masked]
> Subject: [alto] FW: I-D Action:draft-kiesel-alto-3pdisc-03.txt
> 
> Hi,
> 
> However, despite the title still saying "Third-party ALTO server
> discovery", we have updated the draft so that the discovery mechanism
> covers **all** cases. The title of the draft will be changed with the
> next revision of it.
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> | Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
> Registered in England 2832014
> 
> 
> ALTO
> > server to ask.  This is called ALTO server discovery.  This memo

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 26 Jul 2010 07:40:54 +0000

Hi Roni,

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, July 22, 2010 8:48 AM
> To: Martin Stiemerling; [email-masked]
> Subject: RE: [alto] FW: I-D Action:draft-kiesel-alto-3pdisc-03.txt
> 
> Hi,

There is a fundamental difference between geopriv and alto
For geopriv you need to find the server associated with your geo-location, to which your  access-line is bound (or your radio tower). This requires using DHCP to some extend (or PPP). However, ALTO does not require to spot the server that is serving your geo-location but a server in charge of you. This is a bit more relaxed IMHO. 

Second, for geo-location services (e.g., emergency there is a hard requirement to spot the geo-location and thus also the need to upgrade all equipment to deal with new DHCP/PPP options). 

> the tracker. As for the bullet before last, look at the geopriv

For the last bullet: this is not supported by DHCP, given that the DHCP is under the control of the ISP and the user has no meaningful way to find the server manually. 

For the bullet before the last bullet:
The text is probably too strong, as some homegateways will forward unknown DHCP options but some won't. This leaves too much space for deployment issues compared to the DNS SRV RR ALTO server discovery.