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

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 20 Apr 2009 17:02:41 +0200

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-masked]
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

---

From: "Das, Saumitra" <[email-masked]>
Date: Mon, 20 Apr 2009 10:53:45 -0700

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-masked] [mailto:[email-masked]] On Behalf Of Sebastian Kiesel
Sent: Monday, April 20, 2009 8:03 AM
To: [email-masked]
Subject: [alto] ALTO client protocol and Autonomous System Numbers

Hi,

thanks,
   Sebastian

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

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 21 Apr 2009 10:16:06 +0200

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

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 21 Apr 2009 12:06:37 -0400

Hello,

I think what you are asking is this:

If the ALTO protocol uses any type of indirect aggregation (ASNs, PID, etc) as opposed to plain prefixes, does the ALTO Server needs to expand them? I do no think this issue is specific to ASNs.

As long as you have the proper interfaces /query mechanism in place, it seems to me you are free to use an aggregation method that suits your deployment.  The ALTO Protocol draft and the presentation at the last IETF provided examples on PIDs usage and resolution. But that could be ASNs or any other aggregation.

Thanks,

Reinaldo

On 4/21/09 1:16 AM, "Sebastian Kiesel" <[email-masked]> wrote:

---

From: Wang Yan <[email-masked]>
Date: Wed, 22 Apr 2009 17:21:09 +0800

Hello,

I agree with Reinaldo on this point. Any aggregation ID or other indirect ID  implying ASN or other group relationships could be used as a selection. 

Best regards,
 - Yan

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 23 Apr 2009 11:59:45 +0200

Hi Reinaldo,

On Tue, Apr 21, 2009 at 12:06:37PM -0400, Reinaldo Penno wrote:
> If the ALTO protocol uses any type of indirect aggregation (ASNs, PID,
> etc) as opposed to plain prefixes, does the ALTO Server needs to
> expand them? I do no think this issue is specific to ASNs.

You are right, basically my question is not limited to ASNs. However,
so far ASNs were the only proposed kind of identifiers, which do not
have an immediate meaning to a P2P entity (such as IP prefixes) and
which do not have a mapping mechanism to IP prefixes *as part of the
proposed ALTO protocol specification* (such as PIDs).

And I'm still looking for a convincing use case, where the benefits
outweigh the possible complications that may arise if an ALTO client
does not know how to handle ASNs or maps them in a wrong way.

> As long as you have the proper interfaces /query mechanism in place,
> it seems to me you are free to use an aggregation method that suits
> your deployment.  The ALTO Protocol draft and the presentation at the
> last IETF provided examples on PIDs usage and resolution. 

With a flexible naming scheme for the macros one could also mimic other
identifier schemes, e.g., one could define a PID "pid-as1", which
expands to the IP prefixes of AS #1, and so on. The difference of using
"pid-as1" compared to just using "AS #1" in ALTO queries and replies
would be that the ALTO client could rely on an ALTO-internal mapping
mechanism, and the ALTO server would be sure that the ALTO client will
not misinterpret the ALTO guidance due to using a wrong mapping table.

Does this make sense?

Thanks,
    Sebastian

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 23 Apr 2009 12:08:07 -0400

I see two benefits for network operators to use ASNs: (1) ASN can be a
useful abstraction (and level of aggregation) for localization, and (2)
the mapping of ASN-to-IP prefixes changes relatively slowly, perhaps at
a different timescale than changes to ALTO guidance.

I worry a little bit about ALTO clients using their own source(s) of
ASN-to-IP prefixes information. An Internet Routing Registry (IRR) could
be a good third-party source of such information, but they have been
known to be incomplete and/or inaccurate (an IRR tutorial can be found
at http://www.sanog.org/resources/sanog4-IRR-Tutorial-champs.pdf).

Alternatively, a looking glass server could be used, but its usefulness
and accuracy may depend on its location in the Internet topology, e.g.
http://www.traceroute.org/#Looking%20Glass.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sebastian Kiesel
Sent: Thursday, April 23, 2009 6:00 AM
To: Reinaldo Penno
Cc: [email-masked]
Subject: Re: [alto] ALTO client protocol and Autonomous System Numbers

Hi Reinaldo,

Does this make sense?

Thanks,
    Sebastian

-- 
Sebastian Kiesel            mailto:[email-masked]
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

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 23 Apr 2009 12:27:21 -0400

Hello Sebastian,

Yes, they have a mapping mechanism. Please read
draft-penno-alto-protocol-01.txt.

The protocol does not assume the mapping works only for PIDs. It is
independent of the NL-ID type. It could be ASN, PID, OSPF Areas, etc. The
query can resolve any NL-ID into another.

Let me know if it is not clear from reading the spec.

Thanks,

Reinaldo

---

From: Satish Raghunath <[email-masked]>
Date: Thu, 23 Apr 2009 09:58:58 -0700

> Woundy, Richard
> Sent: Thursday, April 23, 2009 9:08 AM
> To: Sebastian Kiesel; Reinaldo Penno
> Cc: [email-masked]

To add to Rich's points, an ALTO client may be an intermediary like an application specific tracker that in turn interfaces with many end-hosts. In such a scenario, using AS numbers enhances scalability of the protocol. Across multiple queries from such an entity, a common subset of AS numbers may appear in responses. Clearly there is gain in abbreviating these responses.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 29 Apr 2009 13:40:11 +0200

Hello Reinaldo,

> draft-penno-alto-protocol-01.txt.

| Applications can already map IPs to ASNs using information from a BGP
| Looking Glass.  To do so, they must download a file of about 1.5MB
| when compressed (as of October 2008, with all information not needed
| for IP to ASN mapping removed) and periodically (perhaps monthly)
| refresh it.

This sounds rather vague to me ... which protocol do I have to use for
download from which address? Which file format is it, i.e., what kind
of parser do I need?

As your protocol proposal is based on HTTP anyway why not just always
offer the file for download from the ALTO server?

| Alternatively, the GetNetworkMap interface defined in this document
| could be extended to map ASNs into a set of IP prefixes.  The
| mappings provided by the ISP would be both smaller and more
| authoritative.

This option sounds better to me.

Thanks,
Sebastian