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

From: [email-masked]
Date: Fri, 20 May 2011 11:33:13 -0700

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

---

From: Richard Alimi <[email-masked]>
Date: Fri, 20 May 2011 11:40:45 -0700

Hi All,

This is the new version of the protocol following a RESTful design.
There are other normative changes (based on feedback at the last
meeting), and I'll send out an email later tonight summarizing those.

Thanks,
Rich

On Fri, May 20, 2011 at 11:33 AM,  <[email-masked]> wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: manbhard <[email-masked]>
Date: Fri, 20 May 2011 20:46:25 -0700

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?

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.

-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

---

From: Richard Alimi <[email-masked]>
Date: Fri, 20 May 2011 22:27:55 -0700

Hi All,

The following is a summary of normative changes in the draft beyond
the newer RESTful design:

- All POST requests have input parameters only in body (no query string)
- Removed the 10% threshold for filtering; the same can be
accomplished with the less than or greater than constraints
- Added '-' to allowed chars for Cost Type and Endpoint Property
- Added Endpoint Property registry (and format for identifier)
- Removed the "shortcut" request for Endpoint Property where the ALTO
Server assumed the input was the source IP address as determined by
the request; this now must be requested using a POST and explicitly
supply the endpoint addresses
- Supported Endpoint Property types are now communicated as
capabilities from an ALTO Server (previously only the Cost Types and
Cost Modes were)
- Clarified the expected floating-point precision relating to cost constraints
- PID Name may now be 64 characters
- Clarified that PIDs contain disjoint sets of Endpoints
- When the Network map changes, the Version Tag MUST be changed
(previously this was a SHOULD)
- Added E_INVALID_COST_MODE, E_INVALID_PROPERTY_TYPE ALTO Errors
- Removed E_INTERNAL_ERROR since HTTP status code and reason should be
good enough
- Equivalent ALTO Servers MAY have same Service ID (it was previously SHOULD)

There are still some discussions to be had, such as the possibility of
using multiple cost types in a single Cost Map.  That will be done on
a separate thread through.

Comments, feedback and questions are welcome!

Thanks,
Rich

---

From: Richard Alimi <[email-masked]>
Date: Fri, 20 May 2011 22:50:15 -0700

Hi Manish,

> 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.

> to send another alto ordinal query with B,C both as destinations to figure

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

---

From: manbhard <[email-masked]>
Date: Fri, 20 May 2011 23:32:18 -0700

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).

-Thanks,
Manish.

---

From: Richard Alimi <[email-masked]>
Date: Mon, 23 May 2011 20:44:59 -0700

Hi Manish,

> 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

---

From: manbhard <[email-masked]>
Date: Mon, 23 May 2011 22:00:32 -0700

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.

-Thanks,
Manish.