Subject: [alto] Reminder to extension authors

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Oct 2013 15:02:18 -0500

Folks: As you prepare slides, etc. for your ALTO extensions, please
consult the latest institutional memory on how to taxonomize or classify
the extensions; this was captured rather succinctly and successfully
during the Berlin IETF side meeting [1].

Enrico and I will be looking to see how we can group the various
extensions under this ontology.  It will make it tractable to understand
and appreciate the extensions as we grapple with them.

Thanks,

[1] http://www.ietf.org/proceedings/87/minutes/minutes-87-alto#ad-hoc

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 28 Oct 2013 10:48:41 -0700

Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( ,
here are some questions/comments.
These comments/questions are from the perspective of creating an ALTO
topology service (suitable for large bandwidth and SDN applications).

http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01
    ALTO for VPNs: Way back when we started talking about "topology"
    like extensions. The concept of ALTO for "controlled or partially
    controlled" environments was floated. It seems that a VPN type of
    service would be the exemplar of such an environment and hence pave
    the way for "restricted environment" use of ALTO.  *Questions*: /Are
    there specific additions to the REST API to offer this some kind of
    security, i.e., to keep others from gaining information about a
    customers VPN? Or would a general approach to security of this
    interface be specified?/
http://tools.ietf.org/html/draft-song-alto-overlay-routing-00
    Extensions for Multiple path choices: In our large bandwidth work we
    considered both path representations as well as graph
    representations. This proposal would extend ALTO by reporting costs
    on multiple possible paths between a source and destination. Hence
    could also work for the large bandwidth case with appropriate
    extensions.  Both in this draft and the VPN draft, we may have the
    situation where the client uses ALTO information to not only make a
    choice but then relay that choice back to the network via some type
    of "reservation interface".
http://tools.ietf.org/html/draft-wu-alto-te-metrics-00
    Defines costs metrics based on OSPF-TE. We would need for such
    metrics for the "general" topology service.
http://tools.ietf.org/html/draft-roome-alto-pid-properties-00
    PID properties -- *Comments*: This is a step on the way to a "NID"
    that we would use in a graph topology (multi-switch) representation,
    i.e., where we'd define a Node with Id and properties.
http://tools.ietf.org/html/draft-seedorf-lmap-alto-02,
http://tools.ietf.org/html/draft-seedorf-cdni-fci-alto-00
    Very interesting applications. Any interest from the authors of
    these drafts in bandwidth/topology type information?

Best Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 28 Oct 2013 17:54:50 +0000

I also think seedorf-lmap is a very interesting draft.

But what I'm most interested in a way to make maps writable.  I want an app to be be able to write to a map therefore influencing its own cost and attributes.

From: Greg Bernstein <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 28, 2013 10:48 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [alto] extension questions and comments

Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( , here are some questions/comments.
These comments/questions are from the perspective of creating an ALTO topology service (suitable for large bandwidth and SDN applications).

http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01
ALTO for VPNs: Way back when we started talking about "topology" like extensions. The concept of ALTO for "controlled or partially controlled" environments was floated. It seems that a VPN type of service would be the exemplar of such an environment and hence pave the way for "restricted environment" use of ALTO.  Questions:  Are there specific additions to the REST API to offer this some kind of security, i.e., to keep others from gaining information about a customers VPN? Or would a general approach to security of this interface be specified?
http://tools.ietf.org/html/draft-song-alto-overlay-routing-00
Extensions for Multiple path choices: In our large bandwidth work we considered both path representations as well as graph representations. This proposal would extend ALTO by reporting costs on multiple possible paths between a source and destination. Hence could also work for the large bandwidth case with appropriate extensions.  Both in this draft and the VPN draft, we may have the situation where the client uses ALTO information to not only make a choice but then relay that choice back to the network via some type of "reservation interface".
http://tools.ietf.org/html/draft-wu-alto-te-metrics-00
Defines costs metrics based on OSPF-TE. We would need for such metrics for the "general" topology service.
http://tools.ietf.org/html/draft-roome-alto-pid-properties-00
PID properties -- Comments: This is a step on the way to a "NID" that we would use in a graph topology (multi-switch) representation, i.e., where we'd define a Node with Id and properties.
http://tools.ietf.org/html/draft-seedorf-lmap-alto-02, http://tools.ietf.org/html/draft-seedorf-cdni-fci-alto-00
Very interesting applications. Any interest from the authors of these drafts in bandwidth/topology type information?

Best Regards

Greg B.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 28 Oct 2013 14:19:56 -0500

> http://tools.ietf.org/html/draft-seedorf-lmap-alto-02,
[...]
>     these drafts in bandwidth/topology type information?

Greg: Speaking for the content of draft-seedorf-lmap-alto, the answer
is "yes".  For now, we are looking at the public dataset as described
in the draft to see what sort of bandwidth information we can glean and
use for ALTO purposes.

Thanks,

- vijay

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 28 Oct 2013 19:30:29 +0000

Hi,

There are some discussions ongoing around something called flow metadata, associated with draft-eckert-intarea-flow-metadata-framework, that I think head somehow in that direction.

Be goode,

On 28 Oct 2013, at 10:54 , Reinaldo Penno (repenno) wrote:

> From: Greg Bernstein <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 28 Oct 2013 23:50:08 -0400

On Mon, Oct 28, 2013 at 1:54 PM, Reinaldo Penno (repenno) <[email-masked]
> wrote:

>  I also think seedorf-lmap is a very interesting draft.
Share the opinion. It is quite interesting indeed! At a first quick look,
it defines another set of metrics (
http://data.fcc.gov/download/measuring-broadband-america/2013/Technical-Appendix-feb-2013.pdfPage
26, which the te-metrics doc may need to look into as well).

It looks like that the draft is still evolving. I can see several
possibilities in defining network maps: one is the geo-location already
well defined in the draft; Table 5 of the Technical-Appendix-feb-2013.pdf
suggests that many maps can be constructed. This is interesting and also
shows that we will need to think more on how to handle a wealth of such
information. Good work!

>  But what I'm most interested in a way to make maps writable.  I want an
> app to be be able to write to a map therefore influencing its own cost and
> attributes.
>

In the particular fcc MBA context, a concrete example is to change the
subscriber tier (end point property). But since you mentioned map, I guess
you are saying e2e (e.g.,  more narrowly bounded app flow). In addition to
flow meta data, Lingli pointed out OneAPI in the context of mobile devices
as another related work:
http://www.gsma.com/oneapi/faq/restful-api-specifications

Richard

> http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01 ALTO for
> VPNs: Way back when we started talking about "topology" like extensions.
> The concept of ALTO for "controlled or partially controlled" environments
> was floated. It seems that a VPN type of service would be the exemplar of
> such an environment and hence pave the way for "restricted environment" use
> of ALTO.  *Questions*: * Are there specific additions to the REST API to
> offer this some kind of security, i.e., to keep others from gaining
> information about a customers VPN? Or would a general approach to security
> of this interface be specified?*
> considered both path representations as well as graph representations. This
> proposal would extend ALTO by reporting costs on multiple possible paths
> between a source and destination. Hence could also work for the large
> bandwidth case with appropriate extensions.  Both in this draft and the VPN
> draft, we may have the situation where the client uses ALTO information to
> not only make a choice but then relay that choice back to the network via
> some type of "reservation interface".
> http://tools.ietf.org/html/draft-wu-alto-te-metrics-00Defines costs
> metrics based on OSPF-TE. We would need for such metrics for the "general"
> topology service.
> http://tools.ietf.org/html/draft-roome-alto-pid-properties-00PID
> properties -- *Comments*: This is a step on the way to a "NID" that we
> would use in a graph topology (multi-switch) representation, i.e., where
> we'd define a Node with Id and properties.
> http://tools.ietf.org/html/draft-seedorf-cdni-fci-alto-00Very interesting
> applications. Any interest from the authors of these drafts in
> bandwidth/topology type information?
>
> Best Regards
>
> Greg B.
>
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 29 Oct 2013 04:13:57 +0000

Inline

From: "Y. Yang" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 28, 2013 8:50 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: Greg Bernstein <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [alto] extension questions and comments

On Mon, Oct 28, 2013 at 1:54 PM, Reinaldo Penno (repenno) <[email-masked]<mailto:[email-masked]>> wrote:
I also think seedorf-lmap is a very interesting draft.

Share the opinion. It is quite interesting indeed! At a first quick look, it defines another set of metrics (http://data.fcc.gov/download/measuring-broadband-america/2013/Technical-Appendix-feb-2013.pdf Page 26, which the te-metrics doc may need to look into as well).

It looks like that the draft is still evolving. I can see several possibilities in defining network maps: one is the geo-location already well defined in the draft; Table 5 of the Technical-Appendix-feb-2013.pdf suggests that many maps can be constructed. This is interesting and also shows that we will need to think more on how to handle a wealth of such information. Good work!

In the particular fcc MBA context, a concrete example is to change the subscriber tier (end point property). But since you mentioned map, I guess you are saying e2e (e.g.,  more narrowly bounded app flow).

[RP] hummm…Not necessarily e2e. If I write to a map and change the cost of reaching  the IP address associated with my application,  I need to be put in a different PID.  I believe the same is true for endpoint properties if you want to actually influence the cost map.

In addition to flow meta data, Lingli pointed out OneAPI in the context of mobile devices as another related work: http://www.gsma.com/oneapi/faq/restful-api-specifications

[RP] My impression is that a lot of the oneapi is already encapsulated by Android and iPhone SDKs.  There is also http://cordova.apache.org which IMO is extremely interesting. Of course, you know, Javascript is like the Borg.

Richard

Best Regards

Greg B.

Thanks,

- vijay

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237<tel:%28510%29%20573-2237>

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

--
--
 =====================================
| Y. Richard Yang <[email-masked]<mailto:[email-masked]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Oct 2013 10:52:50 -0500

On 10/28/2013 10:50 PM, Y. Richard Yang wrote:
> well defined in the draft; Table 5 of the
> Technical-Appendix-feb-2013.pdf suggests that many maps can be
> constructed. This is interesting and also shows that we will need to
> think more on how to handle a wealth of such information. Good work!

Richard: Indeed; we forsee multiple maps coming out from this data once
the approximate locations of the devices has been determined (which is
what Section 6 of the draft is all about).

Some of these maps are fairly esoteric and some of the work we are doing
looks at various "what if" scenarios using the maps we have constructed.
We plan to publish these evolutions as our thinking further coalesces.

Let's chat more in Vancouver.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Oct 2013 11:01:11 -0500

On 10/28/2013 11:13 PM, Reinaldo Penno (repenno) wrote:
> subscriber tier (end point property). But since you mentioned map, I
> guess you are saying e2e (e.g.,  more narrowly bounded app flow).
>
> [RP] hummm…Not necessarily e2e. If I write to a map and change the cost
> of reaching  the IP address associated with my application,  I need to
> be put in a different PID.  I believe the same is true for endpoint
> properties if you want to actually influence the cost map.

Reinaldo: Interesting ... you are proposing an alto.put() mutator,
whereas what we have now is mostly alto.get() accessors.

Once we do this, we are perilously close to sdn/i2rs type of thinking
(I think).  However, if I understand you correctly, you are advocating
a bounded alto.put() functionality ... perhaps an endpoint migrating to
a different PID.  I don't think you are advocating a wholesale
application-specified state insertion into the network.

The use of ALTO in scenarios that require changing the basic networking
plumbing has been discussed in academic papers, at least (at the cost of
a self reference, see [1]).  There has been some discussion in the ALTO
mailing list of such functionality as well, but to date my impression
is that such discussion has been limited due to the overlap between
sdn/i2rs type of work.

[1] Gurbani, V.K., Scharf, M., Lakshman, T.V. and Hilt, V.,
  "Abstracting network state in Software Defined Networks (SDN) for
  rendezvous services," accepted for publication. In Workshop on
  Software Defined Networks (SDN), held in conjunction with IEEE
  International Conference on Communications (ICC), pp. 6627-6632, June
  2012.

Thanks,

- vijay

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 29 Oct 2013 17:03:18 +0000

On 10/29/13 9:01 AM, "Vijay K. Gurbani" <[email-masked]> wrote:

>> [RP] hummmŠNot necessarily e2e. If I write to a map and change the cost
>(I think).  

Right

>However, if I understand you correctly, you are advocating

Something like that: "Is there a PID with low latency? I want to be
there". The app itself does not need to know anything about the network
per se. 

>  International Conference on Communications (ICC), pp. 6627-6632, June

Will read it sir.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 29 Oct 2013 20:53:39 -0400

On Tue, Oct 29, 2013 at 1:03 PM, Reinaldo Penno (repenno) <[email-masked]

> >Once we do this, we are perilously close to sdn/i2rs type of thinking
I wonder how far we can get close to sdn/i2rs and still be safe. It is an
issue that the WG may need to discuss. As someone who works in both ALTO
but also in SDN (a bit self promotion: our Maple SDN controller is getting
attention), I see ALTO as a good place to contribute to SDN, not the whole
SDN space, but a good part of the North Bound API.

> there". The app itself does not need to know anything about the network
This can be a base for an interesting API, and choosing-PID can be more
general than writing to endpoint properties in settings. Here is a sketch
of a use case, in the decision instead of search formulation (using NP
terms) and what the API might look like:

- We define two sets of PIDs, candidate assignment PIDs say cPIDs
(implemented by priority, or rate limit, ... or whatever non-disclosed
internal mechanism), and target PIDs (defining country blocks, ASes, bw
tiers, well-known service blocks...) say tPIDs.

- The ALTO Server announces the metrics, in particular, from cPIDs to tPIDs.

- Client requests an assignment to its cPIDs.

Hence, the preceding ties ALTO Cost Map to a menu based service selection
API. This is quite interesting!

Richard

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 30 Oct 2013 17:29:58 +0000

From: "Y. Yang" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 29, 2013 5:53 PM
To: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Cc: Vijay Gurbani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [alto] extension questions and comments

This can be a base for an interesting API, and choosing-PID can be more general than writing to endpoint properties in settings.

[RP] right, I believe we discussed this in the beginning but there is just too much opportunity for ratholing.  My guess is the the majority of app developer will not care about end property  fine grained control.  App would basically say "I want to be on the high bandwidth PID".

Here is a sketch of a use case, in the decision instead of search formulation (using NP terms) and what the API might look like:

- We define two sets of PIDs, candidate assignment PIDs say cPIDs (implemented by priority, or rate limit, ... or whatever non-disclosed internal mechanism), and target PIDs (defining country blocks, ASes, bw tiers, well-known service blocks...) say tPIDs.

Hence, the preceding ties ALTO Cost Map to a menu based service selection API. This is quite interesting!

[RP] Exactly!

Richard