Re: [alto] ALTO client protocol and Autonomous System Numbers

Sebastian Kiesel <sebastian.kiesel@nw.neclab.eu> Tue, 21 April 2009 08:15 UTC

Return-Path: <Sebastian.Kiesel@nw.neclab.eu>
X-Original-To: alto@core3.amsl.com
Delivered-To: alto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0403A6FF3 for <alto@core3.amsl.com>; Tue, 21 Apr 2009 01:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAdx7rYuZGdV for <alto@core3.amsl.com>; Tue, 21 Apr 2009 01:15:02 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 84D1E3A6FFB for <alto@ietf.org>; Tue, 21 Apr 2009 01:15:02 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4EBB92C01C95B; Tue, 21 Apr 2009 10:16:18 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weSof5DfFFet; Tue, 21 Apr 2009 10:16:18 +0200 (CEST)
Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 237EF2C01C8ED; Tue, 21 Apr 2009 10:16:08 +0200 (CEST)
Received: from foo.nw.neclab.eu ([10.1.6.240]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 10:16:08 +0200
Received: by foo.nw.neclab.eu (sSMTP sendmail emulation); Tue, 21 Apr 2009 10:16:06 +0200
Date: Tue, 21 Apr 2009 10:16:06 +0200
From: Sebastian Kiesel <sebastian.kiesel@nw.neclab.eu>
To: "Das, Saumitra" <saumitra@qualcomm.com>
Message-ID: <20090421081606.GB6367@foo.nw.neclab.eu>
References: <20090420150241.GA6367@foo.nw.neclab.eu> <2D06DE445C2ADE44890118C3F449B9636ECDC5AE@NASANEXMB12.na.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2D06DE445C2ADE44890118C3F449B9636ECDC5AE@NASANEXMB12.na.qualcomm.com>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
X-OriginalArrivalTime: 21 Apr 2009 08:16:08.0890 (UTC) FILETIME=[6CBBE1A0:01C9C259]
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] ALTO client protocol and Autonomous System Numbers
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2009 08:15:03 -0000

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: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of Sebastian Kiesel
> Sent: Monday, April 20, 2009 8:03 AM
> To: alto@ietf.org
> 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:sebastian.kiesel@nw.neclab.eu
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