Subject: [alto] ALTO topology design: separation design

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 24 Feb 2015 17:40:12 -0500

Dear all,

The authors of the ALTO topology draft are working to make progress on key
design issues, in particular, the issues left open at IETF 91:
http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf

One key design choice is using unified PID/Network (Device) node or not;
see slides 17-18 of the proceeding slides for discussions. At IETF 91, the
favor was a separation design (slide 19), but no decision was made. After
much thinking, and evaluation of related work, we propose to proceed with
the separation design. This is similar to emerging general node-graph
design such as that of ONOS, which uses Nodes, Link, Host, EdgeLink, Path.
If you have any objection, please feel free to raise the issues soon.

Thanks.

Richard

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 25 Feb 2015 15:29:16 +0000

Hi Richard,

I think one the key ideas of ALTO is that a PID refers to (potential) locations of application instances, i.e., endpoints. ALTO is a solution to provide topology guidance between endpoints.

With path vector encoding, we have additional entities for “something” that is in the middle between endpoints, e.g., a shared bottleneck of two path vectors. Conceptually, this entity representing a shared bottleneck is quite different to an endpoint: First, in many cases we won’t expect that an application runs instances at such a bottleneck. And second, these entities may use other identifiers. For instance, a switch or a router may not have any globally unique IP address, or even if it has one (e.g., router system address), the network operator may not necessarily be interested in exposing this in an ALTO server, e.g., to P2P applications.

To me, the question of whether to use unified PID comes down to:

1)      Distinguish different types of PIDs, i.e., add some form of “type field” for PIDs. I think we had a related discussion some time ago regarding “Transactional PIDs”.

2)      Add a new entity in addition to PIDs that is used e.g. in the path-vector format, i.e., separation design.

I think both approaches can work. IMHO, one of the constraints for picking a solution would be “legacy” ALTO clients. For instances, let’s assume that an ALTO server offers path-vector style ALTO maps, but not all ALTO clients support it. For instance, a P2P application may only understand “traditional” network and cost maps. In this case, it probably makes sense not to expose in network maps those PIDs a “legacy” application would not care about. This means that path-vector guidance would probably be exposed in a new network map (e.g., different MIME type). Furthermore, I’d argue that in this scenario it could make sense to allow an ALTO server operator to use the same PID names both in the network maps for “legacy” and “path-vector” users, in order to simplify management. In general, I believe that separation is a slightly more natural design choice under these constraints.

Thoughts?

Michael

From: alto [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Tuesday, February 24, 2015 11:40 PM
To: IETF ALTO
Subject: [alto] ALTO topology design: separation design

Dear all,

The authors of the ALTO topology draft are working to make progress on key design issues, in particular, the issues left open at IETF 91:
http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf

One key design choice is using unified PID/Network (Device) node or not; see slides 17-18 of the proceeding slides for discussions. At IETF 91, the favor was a separation design (slide 19), but no decision was made. After much thinking, and evaluation of related work, we propose to proceed with the separation design. This is similar to emerging general node-graph design such as that of ONOS, which uses Nodes, Link, Host, EdgeLink, Path. If you have any objection, please feel free to raise the issues soon.

Thanks.

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 25 Feb 2015 14:19:31 -0500

Michael,

Thanks for the feedback. Please see below.

On Wed, Feb 25, 2015 at 10:29 AM, Scharf, Michael (Michael) <
[email-masked]> wrote:

>  Hi Richard,
>
>
>
> I think one the key ideas of ALTO is that a PID refers to (potential)
> locations of application instances, i.e., endpoints. ALTO is a solution to
> provide topology guidance between endpoints.
>
>
>
> With path vector encoding, we have additional entities for “something”
> that is in the middle between endpoints, e.g., a shared bottleneck of two
> path vectors. Conceptually, this entity representing a shared bottleneck is
> quite different to an endpoint: First, in many cases we won’t expect that
> an application runs instances at such a bottleneck. And second, these
> entities may use other identifiers. For instance, a switch or a router may
> not have any globally unique IP address, or even if it has one (e.g.,
> router system address), the network operator may not necessarily be
> interested in exposing this in an ALTO server, e.g., to P2P applications.
>
>
>
> 1)      Distinguish different types of PIDs, i.e., add some form of “type
> field” for PIDs. I think we had a related discussion some time ago
> regarding “Transactional PIDs”.
>
I tend to have a mixed feeling on adding a type field to mingle different
types of objects into a single class. This is a foundation of the property
graph abstraction and hence has its value. But they appear to be less
natural.

>  2)      Add a new entity in addition to PIDs that is used e.g. in the
> path-vector format, i.e., separation design.
>
 I think both approaches can work. IMHO, one of the constraints for picking
> a solution would be “legacy” ALTO clients. For instances, let’s assume that
> an ALTO server offers path-vector style ALTO maps, but not all ALTO clients
> support it. For instance, a P2P application may only understand
> “traditional” network and cost maps. In this case, it probably makes sense
> not to expose in network maps those PIDs a “legacy” application would not
> care about. This means that path-vector guidance would probably be exposed
> in a new network map (e.g., different MIME type). Furthermore, I’d argue
> that in this scenario it could make sense to allow an ALTO server operator
> to use the same PID names both in the network maps for “legacy” and
> “path-vector” users, in order to simplify management. In general, I believe
> that separation is a slightly more natural design choice under these
> constraints.
>
>
>

Agreed. Considering legacy is an excellent point.

Richard

>  Thoughts?
>
>
>
> Michael
>
>
>
>
>
> *From:* alto [mailto:[email-masked]] *On Behalf Of *Y. Richard Yang
> *Sent:* Tuesday, February 24, 2015 11:40 PM
> *To:* IETF ALTO
> *Subject:* [alto] ALTO topology design: separation design
>
>
>
> Dear all,
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_91_slides_slides-2D91-2Dalto-2D4.pdf&d=AwMGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=XLUiSiiG1puqdedQurbPGwgATXWZip5Am1lcg3DwNgM&s=jwcigZ1MgWFL72LB91wmwPVoe75NQbZSkJdj2HcTO8k&e=>
>
>
>