Subject: Re: [alto] your feedback on draft Multi-Cost ALTO

From: Richard Alimi <[email-masked]>
Date: Mon, 3 Jan 2011 11:17:26 -0800

Hi Sabine,

Thank you very much for the draft and presentation during the ALTO
session.  A couple of comments and questions on the draft:

"However, vector costs provide a robust and natural input to
multi-path connections ..."
Why does exposing multiple costs for each path necessarily help with
multi-path connections?

Regarding multiple cost types:
- The savings in message size could be useful, but I'm not sure how
much it would save in practice.  Given that the changing the protocol
to support multiple cost types should be a small undertaking perhaps
this is just a minor concern.

Regarding statistical information:
- For the P2P case, I'm not convinced about putting statistical
information here. It seems that doing so would be useless without an
accompanying standard protocol for reporting this information to an
ALTO Server?
- For cases such as CDNs (where there an ALTO Server is directly
managed by a CDN provider or by an ISP with an explicit agreement with
the CDN provider), this seems more doable.
- I'm not sure that timeframe, TTL, and reliability are the best way
to capture statistical information for a cost.  In particular, the
definition of "reliability" is a somewhat nebulous -- how is an ALTO
Client supposed to interpret it? For a statistical measure, should
there be a well-defined interpretation of it? There is some additional
discussion on conveying statistical information in the responses to
this posting: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01779.html.
- It may help to have some particular real-world uses that could be
documented in the draft that include a particular optimization being
done, and how statistical information was applied.

Proposed Cost Types:
- I think some of these are endpoint properties instead of cost types?
  But, you do point to a need for an endpoint property registry..
adding this as a TODO for the protocol document :)

Some Nits:
- I don't think you need Cost Length in the encoding.  Arrays in JSON
don't need the length explicitly specified.
- Perhaps you could define a canonical ordering for cost types on the
request. This would make caching automatic and I don't think it
changes the semantics of the query or response.

Next Steps:
- I think the changes to the ALTO Protocol to support multiple cost
types would be minor and doable.  If the WG wishes this to be
included, this could be done.
- For the proposed cost types, we now have a Cost Type registry
defined in the draft-alto-protocol-06.  Any suggested cost types could
probably be split out from this document and, once the registry is
implemented, you could follow through the registration process there.
The same applies for the endpoint properties once a registry is
defined.

Thanks,
Rich

On Tue, Nov 16, 2010 at 8:59 AM, Sabine Randriamasy
<[email-masked]> wrote:
>
> Hi all,
>
> During the ALTO session of the last IETF79, I have presented a personal
> draft proposing to extend the ALTO protocol (i) to support additional Cost
> Types (ii) to get information on multiple Cost Types in one single
> query/response transaction.
>
> I would like to have your feedback on this proposal, in particular, there
> were questions on this presentation that I need to make sure I understood.
>
> Presentation slides can be found here
> http://tools.ietf.org/agenda/79/slides/alto-1.pdf
>
> The draft can be found here
> http://tools.ietf.org/id/draft-randriamasy-alto-multi-cost-00.txt
>
> Thanks in advance
> Best regards
> Sabine
>
> --
>
> ---------------------------------------------------------
> Dr. Sabine RANDRIAMASY
> Alcatel-Lucent Bell Labs France Centre de Villarceaux
> Route de Villejust - 91620 NOZAY - FRANCE
>
> E-MAIL : [email-masked]
> TEL: +33 (0)1 30 77 27 45       2 103 27 45 (On Net)
> ---------------------------------------------------------
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 10 Jan 2011 17:27:58 +0100

Hi Richard,

First of all, all my best wishes for year 2011.

Thank you very much for your questions and comments. Inline are my first 
answers, before I go more deeply in the thread and registration rules 
associated to the Cost Type registry of protocol v6.

Best regards
Sabine

> Why does exposing multiple costs for each path necessarily help with
I should have emphasised the word "vector" and the numerical advantages 
of vector-based (i.e multi-objective) optimization. Indeed, it naturally 
outputs a set of several efficient solutions with comparable 
performances. Having multiple cost metrics is already an advantage for 
EP selection, whatever optimization method is used. Selecting the EPs 
with a vector-based method (outside ALTO scope) is a plus w.r.t. 
reliability of the selected EPs. If one needs for some reason to select 
several EPs, a vector-based method will provide a robust selection.

Vector-based *path* selection that exposes multiple costs, has proven 
useful for multi-path routing and multi-path connections. And 
Vector-based *EP* selection exposing multiple costs for an EP allows to 
get multiple "efficient" EPs, each reachable via a path.
> this is just a minor concern.
I also mentioned savings in number of transactions and time, by getting 
information for all the Cost Type in one single transaction. If it is 
easy to implement it, then this is good news.
> to capture statistical information for a cost.  
I used TTE, that is Time To Expire of the provided information. 
Timeframe, TTE and reliability are attributes of the provided 
information. To avoid confusion with the "Endpoint reliability" 
attribute, I guess I should change the terminology.

Timeframe and TTE are useful for those entities updating the information 
on ALTO servers at regular intervals, which is a compromise between 
timeless averages thjat may be too static and highly variable and noisy 
information.
A usage example can be: an ALTO Client requests information on EP load, 
or Path robustness. Suppose the information on the ALTO Server is valid 
for a timeframe of 4 given hours, say 1pm to 5pm; suppose the ALTO 
client checks it at 3 pm, then the ALTO client will get the EP load 
information together with a TTE of 2 hours.

However, all these attributes need to be further specified.
> In particular, the
> Client supposed to interpret it? 
I agree that the signification of qualitative metrics such as 
reliability MUST be free of any ambiguity and clear throughout the ALTO 
servers, so that their interpretation by ALTO clients be uniform. So 
additonal specification work is necessary.
Note that quantities related to EPs should preferably be used to 
*compare* these EPs, which yields an ordering, rather than be 
interpreted as figures.
> For a statistical measure, should
I'll further check the thread, that indeed contains interesting 
discussions on uncertainty and likelihood.
> done, and how statistical information was applied.
I'll provide examples ellaborated upon the figure 2 of the "Multi-Cost 
ALTO" draft.
> adding this as a TODO for the protocol document :)
Great
> don't need the length explicitly specified.
This is good news.
> changes the semantics of the query or response.
I agree and will check the Cost Type registry rules used for similar 
purposes.
> included, this could be done.
I'm glad to hear that the protocol changes will be minimal.
> The same applies for the endpoint properties once a registry is
Ok.The nexte step then would be to map the registry rules to the cost 
types and their attributes.
> Rich
Thanks for the good discussion points,
Sabine

-- 

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

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