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

[Richard Alimi <[e-mail]>]

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?

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" <[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
> >>>>
> >>
> >>
>