Subject: Re: [alto] some use cases and its considerations in ALTO

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 2 May 2011 20:18:57 +0200

Hi,

On Fri, Apr 29, 2011 at 03:25:55PM +0800, ?????? wrote:
> hi Sebastian ???
> 
>    - firstly, i agree that the creation of the map, which is tightly related
>    to the algorithm, is within the protocol.
>    - secondly, i am not sure the information contained in current map
>    structure is complete or not, because the current protocol describe that :
> 
> 
>    1. the cost map just includes cost type and cost mode
>    2. the network map just includes PID and endpoint address
> 
> does the information include the cell id or ap id?

What would be your optimization strategy that requires exposing cell IDs
to the peers?

Sebastian

---

From: 朱潇 <[email-masked]>
Date: Tue, 3 May 2011 09:45:36 +0800

On Fri, Apr 29, 2011 at 4:57 PM, stefano previdi <[email-masked]> wrote:

> On Apr 29, 2011, at 3:12 AM, 朱潇 wrote:
>
>> hi Sebastian ：
>>        * firstly, i agree that the creation of the map, which is tightly
>> related to the algorithm, is within the protocol.
>>
>
>
> the protocol specifies the semantic of the map content. How you
> came to that (from whatever source) is out of protocol spec.
>
>
>         * secondly, i am not sure the information contained in current map
>>        * the cost map just includes cost type and cost mode
>>
>
>
> I believe the cost mode will reflect the topology layer you leveraged
> in order to build your maps/ecs.
>
> was that specified in the ALTO protocol? or do we have to specified what
exact factor should be included?

>
>         * the network map just includes PID and endpoint address
>>
> it will be reflected in your pid's.
>
> in my understanding, the PID is a kind of self-defined naming system in
ALTO, does they have the same syntax or semantics of the cell id or ap id
defined in GSM or other networks?

> s.
>
>
>
>
>  On Thu, Apr 28, 2011 at 6:40 PM, Sebastian Kiesel <[email-masked]>
>> wrote:
>> On Thu, Apr 28, 2011 at 09:27:51AM +0800, ?????? wrote:
>> > > I agree. But the creation of maps based on the (wireless) topology and
>> > > other {cost,distance,performance,...}-related information as well as
>> > > feeding them into the ALTO server is out of scope of the protocol
>> spec.
>> > >
>> > why does the creation of this map is out of the scope of the protocol
>> spec?
>>
>> Which information to put into the map depends on the network technology,
>> topology, optimization goals, policies (e.g. how much information about
>> the network is an ISP willing to disclose), how much effort you want to
>> spend, etc. So it would be difficult to write down an one-size-fits-all
>> algorithm. Furhermore, the algorithms used for creating the maps may be
>> a field where different ALTO server vendors may come up with different
>> solutions, i.e., market competition.
>>
>> For interoperability between ALTO clients and servers of different
>> vendors it is important that the syntax of the map and the request/reply
>> protocol is clearly specified. This is within the scope of the document.
>>
>> > the ALTO server should provider the information to client to make sure
>> that
>> > P2P application make the appropriated selection for the wireless peer.
>>
>> I agree.
>>
>> In your wireless scenario, is there any kind of guiding information
>> you would like to transport from the ALTO server to the ALTO client,
>> which cannot be expressed with the syntax in the current protocol
>> specification?
>>
>>
>> Thanks,
>> S.
>>
>>
>>
>> --
>> Best wishes,
>>
>> Beijing University of Posts & Telecommunications (BUPT)
>> Zhu Xiao  ( 朱潇 )
>> E-mail: [email-masked]
>> mobile:+86 134-8881-9004
>>
>
>

-- 
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  ( 朱潇 )
E-mail: [email-masked]
mobile:+86 134-8881-9004

---

From: 朱潇 <[email-masked]>
Date: Tue, 3 May 2011 09:48:03 +0800

On Tue, May 3, 2011 at 2:18 AM, Sebastian Kiesel <[email-masked]>wrote:

> in my understanding,currently, the peer in the wireless network, especially
in the mobile network should be avoid be selected because of the limited
network bandwidth and local capabilities, which should be included in ALTO
information. what do you think?

-- 
Best wishes,

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 4 May 2011 23:27:19 +0200

Hi,

> information. what do you think?

this is a reasonable strategy. In GSM/UMTS-style networks, where all
data has to go all the way to the GGSN it is likely to be more efficient
to access a ressource "somewhere in the internet", even if the person
standing right next to you has a copy on his mobile.

In contrast, in a fixed network, the strategy might be to keep the
traffic local, i.e., peers connected to the same BRAS should better talk
to each other than to a distant peer via an expensive long-distance
link.

Both strategies can be implemented without using Cell IDs or DSLAM port
IDs in the ALTO client protocol. This is good, because a normal P2P
software probably does not know about such IDs. A normal P2P app only
knows IP addresses of other peers (e.g. learned from tracker or gossip)
and then has to decide whether to use it or not.

This is how we can hide the cell IDs, etc. from the P2P app: For example,
if you are an mobile + fixed operator, you could define some PIDs:

PID 1 = all the IP prefixes from which you give IP addresses to your
        FTTH customers (look them up in your DHCP server configuration)

PID 2 = all the IP prefixes from which you give IP addresses to your
        DSL customers (look them up in your BRAS / DHCP server 
        configuration)

PID 3 = all the IP prefixes from which you give IP addresses to your
        mobile customers (not sure about that, but maybe look them 
        up in GGSN/NAS/HSS/?? configuration)

PID 4 = IP prefixes used by some parter ISP that has a special
        arrangement with you for very cheap traffic exchange
        (get the IP prefixes from BGP)

PID 5 = IP prefixes "behind" an expensive or constantly congested link

PID 0 = default, if IP address is not in any other PID

Then define some cost map that gives the relative cost, e.g.:

PID 0 = 100  (default cost)
PID 1 = 10
PID 2 = 50
PID 3 = 200
PID 4 = 20
PID 5 = 300

So for crating the maps you need special knowledge and methods fitting
your network technology (e.g. look into DHCP config, listen to BGP, ...).
For now, we do not want to standardize that. 

The interface between ALTO server and ALTO client, which is used for
accessing the maps is in scope of the specifications. This rather simple
interface hides all the details of different access network technologies
(such as cell IDs) from the (peer-to-peer or other) ALTO clients.

Does this make sense to you?

Thanks
Sebastian