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

From: 朱潇 <[email-masked]>
Date: Wed, 27 Apr 2011 09:15:11 +0800

hi, everyone:

have the ALTO considered the use cases of wireless, which means how to make
the selection of the peers in the wireless environment?

could anybody be kind to instruct me if the ALTO have the consideration.

thx in advance!
-- 
Best wishes,

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

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 27 Apr 2011 10:22:35 +0200

Hi,

> the selection of the peers in the wireless environment?

the ALTO protocols and procedures feature mechanisms that can be
leveraged in a mobile / wireless scenario. IMO there are two issues:

1. When a client is moving between different sections of an access
   network it may have to find a new ALTO server which is able
   to give guidance that is useful at the new client position.
   draft-kiesel-alto-3pdisc-05, sec. 1.3 states:

   o  A change of the IP address at an interface invalidates the result
      of the ALTO server discovery procedure.  For instance, if the IP
      address assigned to a mobile host changes due to host mobility, it
      is required to run the ALTO server discovery procedure for the new
      IP address without relying on earlier gained information.

2. The actual strategy (algorithm) for selecting peers is out of scope
   of the standardization process, as there are many different scenarios
   with different constraints and optimization goals (e.g., in a given
   mobile access network, is the backhaul capacity an issue or not?). 
   
   The ALTO client protocol together with a procedure for defining new
   Host Characteristics Attributes (cost types) is able to convey the
   input for a variety of different selection algorithms.

does this make sense?

thanks
sebastian

---

From: stefano previdi <[email-masked]>
Date: Wed, 27 Apr 2011 11:17:33 +0200

>      IP address without relying on earlier gained information.

mobility is often at layer-2 and this mean you will need some other
mechanisms in order to enrich your maps/ecs with wireless-l2 derived
topology info.

I agree with you: not sure these mechanisms needs standardization.

s.

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: 朱潇 <[email-masked]>
Date: Wed, 27 Apr 2011 23:18:23 +0800

hi, Sebastian

thx for your time!
comments inline:D

On Wed, Apr 27, 2011 at 4:22 PM, Sebastian Kiesel <[email-masked]>wrote:

> what is IMO stands for?
> what does the IP address refer to in  "it is required to run the ALTO
> server discovery procedure for the new IP address without relying on earlier
> gained information"?  the new IP address of the roaming user which may
> allocated by GGSN or wifi AP?  however, that allocation process has nothing
> to do with the ALTO server discovery. or it is not correct of  my
> understanding ?
>
> can i understand "how to make the selection is the issues decided by P2P
> application"?
> do you mean the selection algorithms can be self-defined by client itself?
>
> does this make sense?
>
>
> thanks
> sebastian
>

-- 
Best wishes,

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 27 Apr 2011 17:55:08 +0200

> to do with the ALTO server discovery. or it is not correct of  my

if the client (peer) notices that it has received a new ip address from
dhcp,ggsn,etc. it has to re-run the ALTO server discovery, because
getting a new address might be the result of a (significant) movement.

> >   input for a variety of different selection algorithms.
`
> do you mean the selection algorithms can be self-defined by client itself?

yes. the ALTO protocol specification only specifies the protocol for
requesting and receiving information from the ALTO server. This data
can be used for influencing the peer selection. But the actual algorithm
to do the selection is not being standardized, as this is highly
application specific.

regards
sebastian

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 27 Apr 2011 21:59:34 +0200

Hi stefano,

> mechanisms in order to enrich your maps/ecs with wireless-l2 derived

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.

The paragraph above is about ALTO server discovery:

If the client notices that it has been assigned a different IP address,
one reason may be a significant movement in the network, e.g., handover
from one mobility anchor to another, and therefore a new ALTO server
discovery might be required (of course, there might be other reasons for
getting a new IP addres, but doing a new discovery then won't hurt).

Are there any networks using layer-2 mobility which are so huge, that a
client should discover and use different ALTO servers while moving
around even though it can retain the same IP address?

Thanks,
Sebastian

---

From: 朱潇 <[email-masked]>
Date: Thu, 28 Apr 2011 09:27:51 +0800

hi Sebastian :

comments inline:D

On Thu, Apr 28, 2011 at 3:59 AM, Sebastian Kiesel <[email-masked]>wrote:

> why does the creation of this map is out of the scope of the protocol spec?
 the ALTO server should provider the information to client to make sure that
P2P application make the appropriated selection for the wireless peer.

-- 
Best wishes,

---

From: stefano previdi <[email-masked]>
Date: Thu, 28 Apr 2011 08:40:29 +0200

> feeding them into the ALTO server is out of scope of the protocol  

well, yes, that's what I stated in my previous email...

> around even though it can retain the same IP address?

in a clever implementation, the use of a particular ALTO server
is mostly dictated by the boundaries of the infra/routing domain
where the client resides. IOW: as long as you stay within the same
SP infrastructure, there shouldn't be reasons to change ALTO server.

s.

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 28 Apr 2011 10:49:41 +0200

Hi Stefano,

> SP infrastructure, there shouldn't be reasons to change ALTO server.

And moving to another SP implies change of mobile client's IP address?

If this is (almost) always true, a changing IP address is a good
trigger for re-discovery.

Thanks,
Sebastian

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 28 Apr 2011 12:40:36 +0200

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

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

---

From: 朱潇 <[email-masked]>
Date: Fri, 29 Apr 2011 09:12:59 +0800

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?

-- 
Best wishes,

---

From: 朱潇 <[email-masked]>
Date: Fri, 29 Apr 2011 15:25:55 +0800

hi Sebastian ：

-- 
Best wishes,

---

From: stefano previdi <[email-masked]>
Date: Fri, 29 Apr 2011 10:57:46 +0200

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.

> 	• the network map just includes PID and endpoint address

it will be reflected in your pid's.

s.

> On Thu, Apr 28, 2011 at 6:40 PM, Sebastian Kiesel <[email-masked] 
> > wrote: