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

[Richard Alimi <[e-mail]>]

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
<[e-mail]> 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 : [e-mail]
> TEL: [phone]       2 103 27 45 (On Net)
> ---------------------------------------------------------
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>