Subject: [alto] FW: I-D Action:draft-stiemerling-alto-deployments-05.txt

From: Martin Stiemerling <[email-masked]>
Date: Fri, 29 Oct 2010 06:37:00 +0000

Dear all,

There is a slightly updated version of the deployment considerations draft. 

Rich Alimi, Richard Yang, Xianghui Sun, Sebastian and me will come up with a joint proposal how to evolve the document at the next IETF. 

Any comments are appreciated!

  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: Monday, October 25, 2010 4:45 PM
> To: [email-masked]
> Subject: I-D Action:draft-stiemerling-alto-deployments-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : ALTO Deployment Considerations
> 	Author(s)       : M. Stiemerling, S. Kiesel
> 	Filename        : draft-stiemerling-alto-deployments-05.txt
> 	Pages           : 29
> 	Date            : 2010-10-25
> 
> Many Internet applications are used to access resources, such as
> pieces of information or server processes, which are available in
> several equivalent replicas on different hosts.  This includes, but
> is not limited to, peer-to-peer file sharing applications.  The goal
> of Application-Layer Traffic Optimization (ALTO) is to provide
> guidance to these applications, which have to select one or several
> hosts from a set of candidates, that are able to provide a desired
> resource.  The protocol is under specification in the ALTO working
> group.  This memo discusses deployment related issues of ALTO for
> peer-to-peer and CDNs, some preliminary security considerations, and
> also initial guidance for application designers using ALTO.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-stiemerling-alto-deployments-
> 05.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.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1zdGllbWVybGluZy1hbHRvLWRlcGxveW1lbnRzLTA1LnR4dA0K

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Oct 2010 09:17:44 +0200

Hi Martin,

a short question concerning the map-based approach:

"The main assumption for map-based approaches is that the information
provided in these maps is static for a longer period of time, where this
period of time refers to days, but not hours or even minutes. This
assumption is fine, as long as the network operator does not change any
parameter, e.g., routing within the network and to the upstream peers,
IP address assignment stays stable (and thus the mapping to the
partitions).  However, there are several cases where this assumption is
not valid, as:
   1.  ISPs reallocate IPv4 subnets from time to time;
   2.  ISPs reallocate IPv4 subnets on short notice;
   3.  IP prefix blocks may be assigned to a single DSLAM which serves a
variety of access networks."

What about mobile peers? How do they fit into a map-based approach?

Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Martin Stiemerling
Sent: Friday, October 29, 2010 8:37 AM
To: [email-masked]
Subject: [alto] FW: I-D Action:draft-stiemerling-alto-deployments-05.txt

Dear all,

There is a slightly updated version of the deployment considerations
draft. 

Rich Alimi, Richard Yang, Xianghui Sun, Sebastian and me will come up
with a joint proposal how to evolve the document at the next IETF. 

  Martin

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

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 29 Oct 2010 07:47:36 +0000

Hi Christian, 

You are raising a good point, which is not covered by the deployments draft.

Mobile peers will also challenge the map-based approach, unless the preference information always indicates to turn away from these types of peers. This could be the most likely case, i.e., the ISP will configure to rank those mobile peers really bad, so that other peers will not pick them. 

The challenge is in the case where there is more specific configuration needed. For instance, static mobile peers (e.g., UMTS stick in home gateway), might get a slightly better rating, as well as, mobile peers on HDSPA.

However, the rating for such a mobile peer may change rapidly, if the peer starts moving and even changes the access technology (e.g. HSDPA to EDGE). The IP address of the peer will remain the same but the rating will dramatically change. 

I guess this is hard to manage with the map-based approaches. 

Thanks and Cheers to Munich

  Martin

> From: Schmidt, Christian 1. (NSN - DE/Munich)
> [mailto:[email-masked]]
> Sent: Friday, October 29, 2010 9:18 AM
> To: Martin Stiemerling; [email-masked]
> Subject: RE: [alto] FW: I-D Action:draft-stiemerling-alto-deployments-
> 05.txt
> 
> Hi Martin,
>

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Oct 2010 12:42:57 +0200

Hi Martin,

am I right, that mobile peers can be identified by the Alto Server?
If yes, perhaps the Alto Server can make something like a fast check of
the mobile peer position in the map - before offering him as source
peer.
The result of this check must not be perfect, the result should be valid
in a majority of cases.

Br
Christian

-----Original Message-----
From: ext Martin Stiemerling [mailto:[email-masked]] 
Sent: Friday, October 29, 2010 9:48 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]
Subject: RE: [alto] FW: I-D
Action:draft-stiemerling-alto-deployments-05.txt

Hi Christian, 

You are raising a good point, which is not covered by the deployments
draft.

Mobile peers will also challenge the map-based approach, unless the
preference information always indicates to turn away from these types of
peers. This could be the most likely case, i.e., the ISP will configure
to rank those mobile peers really bad, so that other peers will not pick
them. 

The challenge is in the case where there is more specific configuration
needed. For instance, static mobile peers (e.g., UMTS stick in home
gateway), might get a slightly better rating, as well as, mobile peers
on HDSPA.

However, the rating for such a mobile peer may change rapidly, if the
peer starts moving and even changes the access technology (e.g. HSDPA to
EDGE). The IP address of the peer will remain the same but the rating
will dramatically change. 

  Martin