Re: [alto] I-D Action: draft-ietf-alto-protocol-08.txt

[Richard Alimi <[e-mail]>]

Hi Manish,

On Thu, May 26, 2011 at 11:00 PM, manbhard <[e-mail]> wrote:
> Hi Richard,
> Please see inline [MB].
>
> -Thanks,
> Manish.
>
>
> On 5/24/11 5:55 AM, "Richard Alimi" <[e-mail]> wrote:
>
> Hi Manish,
>
> On May 24, 2011 12:57 AM, "manbhard" <[e-mail]> wrote:
>>
>> Hi Richard,
>> Yes, the use-cases that you mention use a scalar distance, however I
>> believe
>> that there will be distance metrics that are vectors. There has been
>> discussion of using network-topology information, and also some form of
>> geographical distance, all of which are vectors. So it would be good if
>> the
>> draft covers the use-case of vector distance that have numerical costs to
>> be
>> used for logical operations, which it lacks currently.
>>
>
> First, can you give more details on use case for vector quantities? It isn't
> clear to me why they are needed. Will using location as a property a
> node/PID suffice if you need to encode topology and associate direction with
> an edge in the graph?
>
> [MB] Not sure I understand the question. If the overlay is a graph,
> numerical operations such as addition/subtraction will not be safe. So for
> nodes A,B,and C in a graph - A->C != A->B + B->C right? The encoding that
> you are suggesting is a bit more complex so maybe I need a bit more
> explanation :)

[ Side note just to ensure the context is clear; please ignore if you
feel its redundant ] There is no "graph" in the current draft.  The
cost matrix is source/destination pairs. My mention of the word
"graph" above referred to the proposed use case of using the matrix to
encode something like an adjacency matrix, with each entry specifying
the cost of an edge in the graph. If ALTO were operating in this mode,
whatever extension document defines it would need to indicate
explicitly how this mode is negotiated.

I am basically wondering why you need costs to be vectors.  Can you
give more details on the use case?

>
> Second, as part of an thread we planned to start this week regarding Cost
> Types, one of the discussion items was going to be whether we wished to
> support opaque Cost Types, which means that the one defining a new Cost Type
> also may indicate its data type and format. It sounds like this would
> satisfy your proposed use case, right?
>
> [MB] I agree with the statement you made previously that the client can make
> the decision about how to use the cost based on cost-type -
>
>> >>> The semantics of a Cost Type (as determined in the registry) should
>> >>> indicate the semantics that apply.  "Ordinal" removes any such
>> >>> semantics and gives them in sorted order of preference.
>
> Consequently, would be good to replace this statement in the draft -
>
> This mode indicates that it is safe to perform numerical operations (e.g.
> summation) on the returned costs.
>
> with something like -
>
> This mode indicates that it is safe to perform logical operations (L.T, EQ,
> G.T.) on the returned costs.

This is the same as "ordinal" right?

> It might also be safe to perform numerical
> operations (e.g. summation) on the returned costs  based on the Cost Type
> field.

We can probably work on the wording here, but it's not quite clear to
me how to clarify it yet. The major thing that "numerical" adds is
magnitude -- you get to know an idea of *how much* better a particular
source/destination pair is, instead of just *whether* its better.  The
Cost Type Registry section already indicates that the semantics must
be documented.  I would have classified the two as:
- "ordinal" lets you do logical operations
- "numerical" lets you do not only logical operations, but also
mathematical operations using the values

Is the mention of "summation" a problem because the use case isn't
obvious to the reader without thinking more deeply about it?

Thanks,
Rich

>
> Thanks,
> Rich
>
>> -Thanks,
>> Manish.
>>
>>
>> On 5/23/11 8:44 PM, "Richard Alimi" <[e-mail]> wrote:
>>
>> > Hi Manish,
>> >
>> > On Fri, May 20, 2011 at 11:32 PM, manbhard <[e-mail]> wrote:
>> >> Hi Richard,
>> >> Thanks for your response. However, the draft seems to suggest that the
>> >> client can perform numerical operations (addition/subtraction) using
>> >> the
>> >> cost, while what we seem to agree is that the numerical Cost mode is
>> >> for
>> >> logical operations (greater than, less than etc).
>> >
>> > One example is an application minimizing the cost to an ISP as
>> > computed by bandwidth distance product, where bandwidth distance
>> > product is computed as the sum of (cost * bandwidth) over all
>> > source/destination pairs.  (Note that the approach in P4P doesn't
>> > immediately optimize for the network, but illustrates the concept
>> > related to the question you asked; see the P4P paper for more
>> > details).
>> >
>> > The CDN draft (draft-penno-alto-cdn) suggests one way in which one
>> > ALTO Provider's costs (e.g., a CDN provider) might be summed with
>> > another ALTO Provider's costs (e.g., a peering ISP) in certain
>> > circumstances (i.e., after normalization, perhaps after agreement
>> > between the two providers) to produce a cost for a longer network
>> > path.
>> >
>> > Both of these examples use the costs in mathematical formulations, as
>> > opposed to only logical comparisons.
>> >
>> > Does this make more sense?
>> >
>> > Thanks,
>> > Rich
>> >
>> >>
>> >> -Thanks,
>> >> Manish.
>> >>
>> >>
>> >> On 5/20/11 10:50 PM, "Richard Alimi" <[e-mail]> wrote:
>> >>
>> >>> Hi Manish,
>> >>>
>> >>> On Fri, May 20, 2011 at 8:46 PM, manbhard <[e-mail]> wrote:
>> >>>> Hi,
>> >>>> Perhaps a late comment but the draft states -
>> >>>>
>> >>>> 5.1.2.1.  Cost Mode: numerical
>> >>>>
>> >>>>   This Cost Mode is indicated by the string 'numerical'.  This mode
>> >>>>   indicates that it is safe to perform numerical operations (e.g.
>> >>>>   summation) on the returned costs.
>> >>>>
>> >>>> It would seem that summation/subtraction is never safe in vector
>> >>>> metrics
>> >>>> like routing costs, geographic distances etc. Is there a use-case for
>> >>>> this?
>> >>>
>> >>> The basic capability that numerical costs provide over ordinal costs
>> >>> is that they reveal relative preference. So, extending your example
>> >>> below, assume that A->B is 10, A->C is 15, and A->D is 100.  Then, an
>> >>> ALTO Client might conclude that A->B is much better than A->D and only
>> >>> somewhat better than A->C.  This numerical information can be used in
>> >>> the optimization objective for an application. One example of how to
>> >>> apply this is the P4P paper from SIGCOMM '08.
>> >>>
>> >>> The semantics of a Cost Type (as determined in the registry) should
>> >>> indicate the semantics that apply.  "Ordinal" removes any such
>> >>> semantics and gives them in sorted order of preference.
>> >>>
>> >>>>
>> >>>> That said, numerical costs are important for logical operations,
>> >>>> i.e., if
>> >>>> A->B is 10 and A->C is 20, we know that B is better than C and do not
>> >>>> have
>> >>>> to send another alto ordinal query with B,C both as destinations to
>> >>>> figure
>> >>>> that out.
>> >>>
>> >>> Yes - you can convert from numerical to ordinal costs. Note that an
>> >>> ALTO Client could request a full ordinal Cost Map to receive all of
>> >>> the information in a single query.  I think the main distinction
>> >>> instead is what was mentioned above.
>> >>>
>> >>> Thanks,
>> >>> Rich
>> >>>
>> >>>>
>> >>>> -Thanks,
>> >>>> Manish.
>> >>>>
>> >>>>
>> >>>> On 5/20/11 11:33 AM, "[e-mail]"
>> >>>> <[e-mail]>
>> >>>> wrote:
>> >>>>
>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> >>>>> directories. This draft is a work item of the Application-Layer
>> >>>>> Traffic
>> >>>>> Optimization Working Group of the IETF.
>> >>>>>
>> >>>>> Title           : ALTO Protocol
>> >>>>> Author(s)       : Richard Alimi
>> >>>>>                           Reinaldo Penno
>> >>>>>                           Y. Richard Yang
>> >>>>> Filename        : draft-ietf-alto-protocol-08.txt
>> >>>>> Pages           : 75
>> >>>>> Date            : 2011-05-20
>> >>>>>
>> >>>>>    Networking applications today already have access to a great
>> >>>>> amount
>> >>>>>    of Inter-Provider network topology information.  For example,
>> >>>>> views
>> >>>>>    of the Internet routing table are easily available at looking
>> >>>>> glass
>> >>>>>    servers and entirely practical to be downloaded by clients.  What
>> >>>>> is
>> >>>>>    missing is knowledge of the underlying network topology from the
>> >>>>> ISP
>> >>>>>    or Content Provider (henceforth referred as Provider) point of
>> >>>>> view.
>> >>>>>    In other words, what a Provider prefers in terms of traffic
>> >>>>>    optimization -- and a way to distribute it.
>> >>>>>
>> >>>>>    The ALTO Service provides information such as preferences of
>> >>>>> network
>> >>>>>    resources with the goal of modifying network resource consumption
>> >>>>>    patterns while maintaining or improving application performance.
>> >>>>>    This document describes a protocol implementing the ALTO Service.
>> >>>>>    While such service would primarily be provided by the network
>> >>>>> (i.e.,
>> >>>>>    the ISP), content providers and third parties could also operate
>> >>>>> this
>> >>>>>    service.  Applications that could use this service are those that
>> >>>>>    have a choice in connection endpoints.  Examples of such
>> >>>>> applications
>> >>>>>    are peer-to-peer (P2P) and content delivery networks.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> A URL for this Internet-Draft is:
>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-alto-protocol-08.txt
>> >>>>>
>> >>>>> Internet-Drafts are also available by anonymous FTP at:
>> >>>>> ftp://ftp.ietf.org/internet-drafts/
>> >>>>>
>> >>>>> This Internet-Draft can be retrieved at:
>> >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-alto-protocol-08.txt
>> >>>>> _______________________________________________
>> >>>>> alto mailing list
>> >>>>> [e-mail]
>> >>>>> https://www.ietf.org/mailman/listinfo/alto
>> >>>>
>> >>>> _______________________________________________
>> >>>> alto mailing list
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/alto
>> >>>>
>> >>
>> >>
>>
>
>