Subject: Re: [alto] Protocol issue: multi-cost information

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 10:02:18 -0700

I don't have any objections with leaving this as an extension.

Sabine - are you still intending to fill out the details in
draft-randriamasy-alto-multi-cost?  Perhaps that could be the first
ALTO protocol extension :)

I could imagine a couple of ways the extension could go:
(1) Design a new service such as the multicost map service.  This is
easy within the current protocol (adding new services to the IRD is
easy without breaking existing clients).
(2) Treat queries for multiple cost types the same as a query for a
cost type that is vector (I think this was basically the way we were
heading in the design discussion previously on the list).  I think
this requires a bit of a change to the base protocol, but one that we
proposed a while back (in particular, opaque cost types).  I'll ping
that thread to see if there are any objections to adding that in this
revision and we can discuss on that thread if there are.

Thanks
Rich

On Sat, Aug 27, 2011 at 12:29 PM, Reinaldo Penno <[email-masked]> wrote:
> I prefer 1.
>
>
> On 8/26/11 11:01 PM, "Enrico Marocco" <[email-masked]>
> wrote:
>
>> The current specification allows cost maps to convey only one type of
>> cost information at a time. It has been pointed out that, in some cases,
>> applications may benefit from the presence of multiple cost-type values
>> in a single cost map (see draft-randriamasy-alto-multi-cost for a
>> detailed description of such use cases) and an extension for allowing
>> that has been proposed.
>>
>> Possible options (please express and possibly motivate your preference):
>>
>>   1. allow only one type per cost map in the core protocol
>>      specification and define the syntax and usage of multi-cost maps
>>      as an extension;
>>
>>   2. extend the core protocol specification to allow multi-cost
>>      information to be queried and provided in base responses;
>>
>>   3. other.
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 24 Oct 2011 19:52:21 +0200

> ALTO protocol extension :)
Hi

Yes, I am working on it. The trade-off between options 1 and 2, depends 
on the service.

- For the EP Cost Service, (POST method), option 2  providing a vector 
or array of multiple EP Costs or Properties seems to be the simplest way.
- For the Filtered Cost Map service (POST method), option 2 also looks 
easily feasible if the filtered volume of information is moderate 
(assuming we know what moderate means).
The 2 above services use an order for the components of the 
cost/properties vector that is specifed in the IRD of the ALTO Server. 
Which means that the multi-Cost/Property  Service would be implicitely 
declared in the IRD.

- For the Cost Map Service (Get method), we may bump into scalability 
issues id the map is "too big". In that case option 1 looks preferable, 
with possibly a limitation on the number of Cost maps per ALTO 
transactions specified in the IRD.

Sabine

-- 

---------------------------------------------------------
Sabine RANDRIAMASY
Alcatel-Lucent Bell Labs France 
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE

E-MAIL : [email-masked]
TEL: +33 (0)1 30 77 27 45 
         (On Net) 2 103 27 45
---------------------------------------------------------

---

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 12:09:14 -0700

On Mon, Oct 24, 2011 at 10:52 AM, Sabine Randriamasy
<[email-masked]> wrote:
> Yes, I am working on it. The trade-off between options 1 and 2, depends on
> the service.
>
> - For the EP Cost Service, (POST method), option 2  providing a vector or
> array of multiple EP Costs or Properties seems to be the simplest way.
> easily feasible if the filtered volume of information is moderate (assuming
> we know what moderate means).
> The 2 above services use an order for the components of the cost/properties
> vector that is specifed in the IRD of the ALTO Server. Which means that the
> multi-Cost/Property  Service would be implicitely declared in the IRD.
>
> - For the Cost Map Service (Get method), we may bump into scalability issues
> id the map is "too big". In that case option 1 looks preferable, with
> possibly a limitation on the number of Cost maps per ALTO transactions
> specified in the IRD.

Just to keep options open, another possibility is to do a POST to the
server, and the server may redirect to an alternate location from
which the client can perform a GET.

Rich

> Alcatel-Lucent Bell Labs France Centre de Villarceau
> TEL: +33 (0)1 30 77 27 45         (On Net) 2 103 27 45