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

From: Richard Alimi <[email-masked]>
Date: Tue, 24 May 2011 05:55:27 -0700

Hi Manish,

On May 24, 2011 12:57 AM, "manbhard" <[email-masked]> 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?

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?

Thanks,
Rich

> -Thanks,
> Manish.
>
>
> On 5/23/11 8:44 PM, "Richard Alimi" <[email-masked]> wrote:
>
> > Hi Manish,
> >
> > On Fri, May 20, 2011 at 11:32 PM, manbhard <[email-masked]> 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" <[email-masked]> wrote:
> >>
> >>> Hi Manish,
> >>>
> >>> On Fri, May 20, 2011 at 8:46 PM, manbhard <[email-masked]> 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, "[email-masked]" <
[email-masked]>
> >>>> 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
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/alto
> >>>>
> >>>> _______________________________________________
> >>>> alto mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/alto
> >>>>
> >>
> >>
>

---

From: manbhard <[email-masked]>
Date: Thu, 26 May 2011 23:00:57 -0700

Hi Richard,
Please see inline [MB].

-Thanks,
Manish.

On 5/24/11 5:55 AM, "Richard Alimi" <[email-masked]> wrote:

>> > geographical distance, all of which are vectors. So it would be good if the
> 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 :)
> 
> 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 -
> 
> Consequently, would be good to replace this statement in the draft -
> 
> This mode indicates that it is safe to perform numerical operations (e.g.
> 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.
>> >
>> >
the
for
>>>>> > >>> On Fri, May 20, 2011 at 8:46 PM, manbhard <[email-masked]> >>>>>
wrote:
>>>>>> > >>>> like routing costs, geographic distances etc. Is there a use-case
>>>>>> for this?
>>>>> > >>>
>>>>>> > >>>> 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.
>>>>> > >>>
>>>>>> > >>>> On 5/20/11 11:33 AM, "[email-masked]"
>>>>>> <[email-masked]>
>>>>>> > >>>> wrote:
>>>>>> > >>>>
Traffic
amount
views
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.
network
(i.e.,
>>>>>>> > >>>>>    the ISP), content providers and third parties could also
>>>>>>> operate this

---

From: Richard Alimi <[email-masked]>
Date: Thu, 26 May 2011 23:32:50 -0700

Hi Manish,

On Thu, May 26, 2011 at 11:00 PM, manbhard <[email-masked]> wrote:
> [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?

> G.T.) on the returned costs.

This is the same as "ordinal" right?

> It might also be safe to perform numerical

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