Hi Saumitra, I know that there are *simulation* based studies out there, which use an "AS hop count" as the metric for optimization, and I think we should support this kind of metric. I'm more wondering what is a practical approach for *implementation* in the real world...
excerpt from draft-marocco-alto-problem-statement-05.txt: > > +------+ > +-----+ | Peers > +-----+ +------+ +=====| |--+ > | |.......| |====+ +--*--+ > +-----+ +------+ | * > Source of ALTO | * > topological service | +--*--+ > information +=====| | Super-peer > +-----+ (Tracker, proxy) > Legend: > === ALTO client protocol > *** Application protocol (out of scope) > ... Provisioning or initialization (out of scope) > > > > Figure 1 - Overview of protocol interaction between ALTO elements Let's consider the ALTO client protocol (===== lines): If we assume a "sorting oracle" approach, I agree that the peers and trackers on the right side should be able to use the ALTO client protocol for asking the oracle "please sort IP address ranges 1.1.1.1/32, 2.2.0.0/16, and 3.3.3.0/24 according to the number of AS hops, as counted from my own location" If we assume an infoexport/p4p approach, I think it should be possible to download a topology map, which says "the distance between 1.1.1.1/32 and 2.2.0.0/16 is 5 AS hops, while 2.2.0.0/16 to 3.3.3.0/24 is 2 AS hops." The question I'm asking is, if we consider the ALTO client protocol (===== lines), does it make any sense to convey the actual AS numbers to/from the peers/trackers on the right side of the figure (as opposed to using only metrics, which are derived from the AS topology). That is, if we assume a "sorting oracle" approach, do we need the protocol being able to express a question like "dear oracle, please sort AS #1, AS #5, and AS #1001 according to <whatever metric>"? Or if we consider the infoexport approach, and the ALTO client receives a reply like: cidr:10/8:10 asn:0:5 cidr:10.1/16:20 cidr:10.2/16:-10 is it reasonable to assume that a significant number of peers/trackers can process the second line reasonably? Wouldn't it be better to mandate that the second line has to be expanded to the corresponding cidr lines at the ALTO server side, to ensure that the ALTO client does not have to deal with AS numbers? Of course the routing between the Autonomous Systems and the corresponding peering agreements is what network operators care about, and I have no doubt that the ALTO provisioning interface (..... lines, which is out of scope for now) might have to deal with AS Numbers. The only question I'm asking is whether there is any reason why we should expose these AS numbers directly to the P2P peers / trackers / etc. Am I missing an important use case? Thanks, Sebastian On Mon, Apr 20, 2009 at 10:53:45AM -0700, Das, Saumitra wrote: > Hi Sebastian, > > By peer-to-peer software entities what do you mean exactly, the client or > the service? > > Even if the ALTO service uses ASNs, it could still use client IPs do its > own mapping to ASNs. Or a tracker could provide HLA (ASNs) for the peer list > if the ALTO service used by a client needs that as input. > > I think there are papers that use ASN base locality. > > Thanks > Saumitra > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Sebastian Kiesel > Sent: Monday, April 20, 2009 8:03 AM > To: [email protected] > Subject: [alto] ALTO client protocol and Autonomous System Numbers > > Hi, > > in the ALTO client protocol, host location attributes are used to > describe the location of one or a group of hosts in the network > topology, for which ALTO guidance is requested or expressed. > > Several solution proposals say that in addition to the obvious approach > of using IP addresses or IP prefixes, one could also use Autonomous > System Numbers (ASNs) as host location attributes. I am wondering > whether this is more a hypothetical idea, or whether this has actually > been tested, e.g., in one of the field trials? > What is the advantage of conveying ASNs to the peer-to-peer software > entities, which probably don't have a module for mappings from IP > addresses to ASNs, as this was generally not needed so far? > > thanks, > Sebastian > -- Sebastian Kiesel mailto:[email protected] 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
