Subject: Re: [alto] Comments to draft-ietf-alto-reqs-00

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 1 Jul 2009 23:24:36 +0200

Hi Haibin,

I know this section needs work, let me try to explain my reasoning.

On Wed, Jul 01, 2009 at 10:34:41AM +0800, Song Haibin wrote:
> Hi, 
> 
> REQ.  ARv00-26: The ALTO server discovery mechanism SHOULD be independent of
> specific link-layer protocols or access network architectures.  For example,
> many broadband access networks use DHCP for configuration, while others use
> PPPoE. In contrast, DNS is available in virtually all Internet access
> networks.
> 
> What is the meaning of "independent of ..."? I saw a lot of discovery
> mechanisms related to DHCP, please refer to
> http://tools.ietf.org/html/draft-ietf-geopriv-lis-discovery-11.

Well, there is nothing wrong with defining a discovery mechanism based
on DHCP. However, we must be aware that there is a significant number of
broadband customers that are not configured using DHCP. For example,
virtually all residential ADSL lines in Germany use PPPoE. So a quick
conclusion would be, that if we define a DHCP option, we should also
define an equivalent for PPP.

However, there is another issue. We can imagine scenarios with several
ALTO servers, each having only partial information ("my Internet view").
A tracker performing a third-party ALTO query on behalf of a peer would
have to send the query to that ALTO server which can give the best
guidance to the considered peer. 

A mechanism similar to BEP-22 could be used by the tracker to figure out
which ALTO server can give the best guidance to a specific peer. Once
we have such a mechanism, it could also be used by the peer itself to
find the nearest ALTO server, thus making a DHCP/PPP option
unneccessary.

Does this make sense to you?

Thanks,
Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
Network Research Division   tel:+49-6221-4342-232   fax:+49-6221-4342-155
NEC Laboratories Europe     Kurfuerstenanlage 36, 69115 Heidelberg, Germany
--
NEC Europe Limited          Registered in England 2832014
Registered Office           NEC House, 1 Victoria Road, London W3 6BL

---

From: Song Haibin <[email-masked]>
Date: Thu, 02 Jul 2009 10:46:54 +0800

Hi Sebastian,

See inline.  

>> REQ.  ARv00-26: The ALTO server discovery mechanism SHOULD be 
>> independent of specific link-layer protocols or access network 
>> architectures.  For example, many broadband access networks use DHCP 
>> for configuration, while others use PPPoE. In contrast, DNS is 
>> available in virtually all Internet access networks.
>> 
>Well, there is nothing wrong with defining a discovery 
>mechanism based on DHCP. However, we must be aware that there 
>is a significant number of broadband customers that are not 
>configured using DHCP. For example, virtually all residential 
>ADSL lines in Germany use PPPoE. So a quick conclusion would 
>be, that if we define a DHCP option, we should also define an 
>equivalent for PPP.
>

I think it is the ALTO service provider who should consider its network
deployment characteristics to choose one or more appropriate discovery
mechanisms. 

>
>
>However, there is another issue. We can imagine scenarios with 
>several ALTO servers, each having only partial information 
>("my Internet view").
>A tracker performing a third-party ALTO query on behalf of a 
>peer would have to send the query to that ALTO server which 
>can give the best guidance to the considered peer. 
>
>A mechanism similar to BEP-22 could be used by the tracker to 
>figure out which ALTO server can give the best guidance to a 
>specific peer. Once we have such a mechanism, it could also be 
>used by the peer itself to find the nearest ALTO server, thus 
>making a DHCP/PPP option unneccessary.
>
It has the following limitations:

(1) This method assumes that the access network provider also
   provides the reverse DNS record and they control the domain that is
   indicated in the "PTR" record.  (In most cases it is true, but not
   always)

(2) Furthermore, this method might not apply where a host is given a
   domain name that is different from the domain name of the access
   network.

(3) In case of NAT and a public ALTO server, it requires the ALTO
   client to know its public IP address.

Haibin

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 2 Jul 2009 15:56:55 +0200

> deployment characteristics to choose one or more appropriate discovery

... and we probably should offer a sufficient number of standardized
discovery mechanisms to choose from, which together cover at least most
of the relevant deployment scenarios and use cases.

>    domain name that is different from the domain name of the access

I don't see why/how these conditions would break BEP-22, although some
coordination between several parties (DNS administrators) might be
required. And at least for most residential customers these limitations
won't apply anyhow.

Please be aware that I am *not* saying that we should use exactly BEP-22
for ALTO server discovery, but maybe we should invent a similar
mechanism which can solve the problem of where to send third-party queries.

>    client to know its public IP address.

I agree. STUN might be an option.

Sebastian