Subject: [alto] ALTO Side Meeting

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 12 Mar 2013 13:59:29 -0400

Dear all,

We have revised the side meeting plan a bit. The current schedule is at:
https://docs.google.com/document/d/1DgVx7_xrF4ZipwflVnlvvylsndJ9I57gJTD8_Hj7ywo/edit

Any comments or suggestions will be appreciated.

Hope to see you there.

Richard, Reinaldo, Young

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Wed, 13 Mar 2013 16:50:47 +0000

Hi Richard, Reinaldo and all,

I am not attending the IETF meeting this time and will probably not be able to listen to the side meeting at 8:15 PM

I believe the take aways of this meeting will base further WG discussions to prepare future ALTO work.
So extension proposals such as Multi-Cost ALTO (http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07) and ALTO Cost Schedule (http://tools.ietf.org/html/draft-randriamasy-alto-cost-schedule-02.txt) are I hope still part of the potential extension items.

Where  as Multi-Cost has been presented a number of times, I'd like to draw attention on the last developments of the ALTO Cost schedule draft, in particular with a use case for SDN where the Cost schedule may help for application traffic balancing given that load balancing is an important topic to the SDN RG. The slides although not presented at the last WG meeting, can be seen here http://tools.ietf.org/agenda/85/slides/slides-85-alto-4.pdf

Thanks,
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Y. Richard Yang
Envoyé : mardi 12 mars 2013 18:59
À : IETF ALTO
Objet : [alto] ALTO Side Meeting

Dear all,

Hope to see you there.

Richard, Reinaldo, Young

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Wed, 13 Mar 2013 18:13:27 +0000

Hi all,

I don't mean this last minute topic to be discussed this evening, but for further discussions on potential extensions I'd like to resume another proposal made on the ALTOEXT mailing list, before the i2aex meeting in Paris.

Ben suggested to introduce "the ability to "name" cost maps so that a single Information Resource Directory can link multiple cost maps with the same cost type & cost mode to a single network map." (see attached e-mail). One goal was to provide, for a given Cost Type and Mode, multiple cost maps depending on qualitative conditions that Ben names "circumstance". A circumstance reflecting a given policy.

I'd like to bring another use case where providing different values for a same cost type can help optimizing the Endpoint choice. Typically when the path to this endpoint starts from a multi technology access network and the Endpoint Cost is impacted by which access technology is used for the first hop from the terminal using the EP resource.

Let's assume a terminal sitting in a LTE network uses the Endpoint Cost Service in an ALTO deployment scenario such as the Cascaded ALTO Service described in section 6.1 of http://tools.ietf.org/html/draft-ietf-alto-deployments-06. We may have a local ALTO Server reporting e.g. 'routingcost' to the PDN Gateway with values depending on qualitative "circumstances" such as cellular, trusted wifi access, SLA... and likely to significantly impact the QoE. The remaining cost from the PDN GW to the EP can be calculated by a regular ALTO Server.

One way to support this is to introduce some cost attribute called e.g. "value name". In an IRD it could be represented with an array of 1 or more elements taking value "circumstanceN" of type "string".

In the IRD we may have something as follows (and modulo syntax errors), with "circumstanceN" taking values such as "cellular", "trusted-wifi", "policyX", "SLAtype"...

For the Cost map Service:

...
"capabilities" {
"cost-types" : ["routingcost"],
"value-name" : ["circumstance1", "circumstance2"], },
"media-types": [
"application/alto-costmap+json"
],
"uri": "http://alto.ietf.org/costmap/routingcost/numerical/circumstance"
...

For the ECS:

...
"capabilities" {
"cost-types" : ["routingcost"],
"value-name" : ["circumstance1", "circumstance2"], },
"media-types": [
"application/alto-endpointcost+json"
],
"uri": "http://alto.ietf.org/endpointcost/rc-num/circumstance"
...

The ALTO Client  knows which one of the Cost Maps or ECS values to request and puts the appropriate name in its request. Where as the ALTO Server on its side has no clue on which value to provide.

Does that sound reasonable? I have a bunch of example figures illustrating the advantages for ECS on cascaded ALTO Servers in a multi RAT access network.

Thanks,
Sabine

Dear all,

Hope to see you there.

Richard, Reinaldo, Young

Subject: Re: [altoext] altoext: Call for participation
From: Ben Niven-Jenkins <[email-masked]>
To: Jan Seedorf <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Gurbani, Vijay K (Vijay)" <[email-masked]>
Date: Thu, 8 Mar 2012 17:11:04 +0000
List-Id: Non-WG list for discussions related to ALTO Protocol Extensions <altoext.ietf.org>

Jan,

On 8 Mar 2012, at 15:58, Jan Seedorf wrote:

> Ben,
> 
> Quick question:
>> - The ability to "name" cost maps so that a single Information Resource
>> Directory can link multiple cost maps with the same cost type & cost mode to
>> a single network map.
> Why would you need that?

I am thinking through a use case where certain policies could be expressed as ALTO cost maps. 

There has always been the implicit assumption in ALTO that the ALTO server could provide different maps to different applications. This is an extension of that concept but where a single application needs to retrieve multiple cost maps (for the same network map) depending on circumstance but the ALTO server won't know the circumstance so cannot determine from the application's ALTO request which cost map to serve.

I could achieve something similar by minting a different cost-type per cost map (linked to a the same network map) but that seems ugly compared to incorporating something like a name/title property in an IRD entry.

Ben

> 
> - Jan
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Ben Niven-Jenkins
>> Sent: Tuesday, February 07, 2012 8:43 PM
>> To: Vijay K. Gurbani
>> Cc: [email-masked]
>> Subject: Re: [altoext] altoext: Call for participation
>> 
>> Hi Vijay,
>> 
>> On 7 Feb 2012, at 16:58, Vijay K. Gurbani wrote:
>> 
>>> Folks: Enrico and I have put together a short draft that explores the
>>> evolution and extension of ALTO as a protocol [1].  At the Taipei
>>> IETF, there was a discussion on the ALTO evolution towards the tail end
>>> of the session.
>> 
>> <snip>
>> 
>>> It will be great if we can foster discussions towards extending
>>> ALTO in new domains culminating in a BoF in Paris.  Your views
>>> on [1] are solicited as part of a larger discussions on extending
>>> ALTO.  We need to form a "community of interest" to identify a
>>> possible problem statement and the work to be done.
>> 
>> Firstly I have to say I'm a little confused as to what is driving this level of
>> "formal" structure as I think many of the items listed in your draft could be
>> considered as relatively incremental changes that could be handled in the
>> normal way within the ALTO WG today by folks writing drafts etc.
>> 
>> However there is at least one thing your draft touches on that I think is more
>> architectural in nature which is extending ALTO to carry large amounts of
>> application data, e.g. what content is on a cache, what applications are
>> installed in a server etc. and I think we need to consider whether ALTO is
>> really the best mechanism for conveying that information and if it's decided
>> that ALTO is a good fit then whether the use cases are best served by
>> overloading existing ALTO semantics (e.g. end point properties) or by
>> extending ALTO with additional information services to deliver that data.
>> 
>>> Folks who would
>>> like to produce drafts on their positions are encouraged to do so as
>>> part identifying the problem statement and outlining the work to be
>>> done.
>> 
>> I have a couple of use cases I'm thinking about that aren't very well baked yet
>> and I won't have time to write any drafts before Paris but in brief are:
>> 
>> - The ability to "name" cost maps so that a single Information Resource
>> Directory can link multiple cost maps with the same cost type & cost mode to
>> a single network map.
>> 
>> - The ability to have a static PID identifier/property as today an ALTO server
>> can change PID names at will and if an ALTO client needs to tie PIDs to
>> something else it can't rely on the PID name to maintain the mapping it
>> requires.
>> 
>> Ben
>> 
>> 
>>> 
>>> Thanks,
>>> 
>>> [1] http://tools.ietf.org/html/draft-marocco-alto-next-00
>>> 
>>> - vijay
>>> --
>>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>>> Email: vkg@{bell-labs.com,acm.org} / [email-masked]
>>> Web:   http://ect.bell-labs.com/who/vkg/
>>> _______________________________________________
>>> altoext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/altoext
>> 
>> _______________________________________________
>> altoext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/altoext

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 13 Mar 2013 19:48:48 -0400

Dear all,

This is a reminder that we will have a side meeting from 8:15 to 9:45 PM
at Caribbean VII.

Some draft slides are available at Dropbox:
https://www.dropbox.com/sh/vbbmy91nrcpne3i/M-hg-CfI5r

Since it is an informal side meeting, we will not have jabber/Webex
support. Tina kindly offered a bridge:

To connect to the Web Conference:****

=============================****

Click here:
https://connect9.uc.att.com/service32/meet/?ExEventID=85875478&CT=M****

** **

TO CONNECT WITH YOUR *TELEPHONE ONLY* (no computer):****

 ===================================================****

1. Choose one of the following numbers to dial:****

If you are calling from an office location with on-site number(s) (listed
below), try this number first. If you do not have on-site access, or you
are not a member of the host's company/organization, use one of the other
numbers shown.****

      * Toll-Free Number (in USA): 888-858-6182.****

      * Caller-Paid number: 646-746-3029****

      * Blackberry (Toll-Free Number): 888-858-6182x5875478#****

      * A number in your country or in a country close to you (may be toll
free):
https://www.teleconference.att.com/servlet/glbAccess?process=1&accessNumber=8888586182&accessCode=5875478
****

2. When prompted, enter the Meeting Access Code: 5875478#

Richard