Re: [alto] ALTO Side Meeting - resuming an extension topic for futher discussions

["RANDRIAMASY, SABINE (SABINE)" <[e-mail]>]

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


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

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

--- Begin Message ---

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: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Ben Niven-Jenkins
>> Sent: Tuesday, February 07, 2012 8:43 PM
>> To: Vijay K. Gurbani
>> Cc: [e-mail]
>> 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} / [e-mail]
>>> Web:   http://ect.bell-labs.com/who/vkg/
>>> _______________________________________________
>>> altoext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/altoext
>> 
>> _______________________________________________
>> altoext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/altoext

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

--- End Message ---