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

[Martin Stiemerling <[e-mail]>]

Hi Christian, 

You're right in the case of the network operator also operating the ALTO server. The operator can feed this information to the ALTO server. 

  Martin

[e-mail]

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: Schmidt, Christian 1. (NSN - DE/Munich)
> [mailto:[e-mail]]
> Sent: Friday, October 29, 2010 12:43 PM
> To: Martin Stiemerling; [e-mail]
> Subject: RE: [alto] FW: I-D Action:draft-stiemerling-alto-deployments-
> 05.txt
> 
> 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:[e-mail]]
> Sent: Friday, October 29, 2010 9:48 AM
> To: Schmidt, Christian 1. (NSN - DE/Munich); [e-mail]
> 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.
> 
> I guess this is hard to manage with the map-based approaches.
> 
> Thanks and Cheers to Munich
> 
>   Martin
> 
> 
> > -----Original Message-----
> > From: Schmidt, Christian 1. (NSN - DE/Munich)
> > [mailto:[e-mail]]
> > Sent: Friday, October 29, 2010 9:18 AM
> > To: Martin Stiemerling; [e-mail]
> > Subject: RE: [alto] FW: I-D Action:draft-stiemerling-alto-
> deployments-
> > 05.txt
> >
> > 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> > ext Martin Stiemerling
> > Sent: Friday, October 29, 2010 8:37 AM
> > To: [e-mail]
> > 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.
> >
> > Any comments are appreciated!
> >
> >   Martin
> >
> 
> 
> [e-mail]
> 
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014