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

[manbhard <[e-mail]>]

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 :)
> 
> 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. It might also be safe to perform numerical
> operations (e.g. summation) on the returned costs  based on the Cost Type
> field.
> 
> 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
>>>>>> > >>>>
>>>> > >>
>>>> > >>
>> >
>