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