Re: [p2pi] Information in an ALTO protocol

[Laird Popkin <[e-mail]>]

This is a very good discussion.

Responding to the comment that topology is "Useful, but hard to use without latency measurments (and IMHO
also indicators of congestion)." I would agree that a realtime, detailed topology would be very hard to provide. But even a broad, static topology has a lot of value, and that's easier to provide. That is, if an ISP can provide a list of IP prefixes that identify users in a metro area, and adjacent metro areas, we can connect people based on that and improve performance and efficiency, without knowing anything about the physical network or individual link status.

Also keep in mind that ALTO only guides initial peer selection (i.e. the endpoints of the streams). The transport layer (BGP, etc.) guides the actual routing of the data, and the applications adapt based on observed throughput. So ALTO doesn't have to solve everything (congestion, real-time conditions) to be useful - it just has to be better than not knowing anything.

- Laird Popkin, CTO, Pando Networks
  mobile: [phone]

----- Original Message -----
From: "John Leslie" <[e-mail]>
To: "Vijay K. Gurbani" <[e-mail]>
Cc: [e-mail]
Sent: Thursday, August 14, 2008 1:42:49 PM (GMT-0800) America/Los_Angeles
Subject: Re: [p2pi] Information in an ALTO protocol

Vijay K. Gurbani <[e-mail]> wrote:
> 
> I think that which parameters to gather will turn out to be an
> interesting topic to nail down.

   Interesting, certainly; but IMHO unwise to nail down too tightly.

> At present, we have the following discrete pieces of information
> mentioned in the post-BoF charter:
> 
>   (1) Routing preferences
>   (2) Priority values

   These are a bit amorphous...

>   (3) AS numbers

   Sometimes very useful; sometimes not...

>   (4) Geographic location

   Often wildly inaccurate, and even more often quite unrelated to
network topology. Would be _very_ useful in an alternate universe where
routing found next-hops _physically_ closer to the destination...

> Add to this the two more:
> 
>   (5) Policies

   Clearly potentially useful

>   (6) Topology

   Useful, but hard to use without latency measurments (and IMHO
also indicators of congestion).

> 1, 2, and 5 are something that the network operator is in possession
> of.

   Each BGP router will have these, very likely reflecting configuration
choices of the ISP. But I'm not convinced they're useful unless you
know you'll pass through that router. Even then, what you actually
experience is the aggregate of all routers you pass through...

> 3 and 4 can be gleaned in some manner (probably not using
> any standardized APIs but well known services, nonetheless.)

   AS numbers are reasonably accurately gleaned; geographic location
is not nearly as accurate.

> 6 can be provided by the network operator or approximated using
> synthetic coordinate systems and the like.

   Actual topology is likely to change without warning; so you should
be prepared for it to prove wildly inaccurate. More often than not,
it turns out to be only roughly approximated or hopelessly optimistic.

> Information that has been deemed out of scope based on list
> discussion is:
> 
>   (1) Last hop bandwidth

   The most useful number yet listed, _if_ folks will give it to us
and we interpret it correctly...

>   (reason: too much uncertainty -- are we talking about upload or
>   download bandwidth?

   Both, of course (though too often the upstream dominates).

>  Provisioned band-width or current snapshot?

   Provisioned, of course (though it would be good to know penalty-box
bandwidth too)

>   User privacy concerns, ISP marketing concerns, etc.

   These are by no means limited to last-hop bandwidth. _Any_ question
we might ask might generate a "none of your business" reply -- we
need to allow for that.

   Besides, last-hop bandwidth (provisioned) can't really be hidden.
If the ISP doesn't want to provide it, a third party can...

> In short, while this is a good research problem, it may not be a
> good piece of information to be provided by ALTO.)

   We'd be foolish to design a protocol which _isn't_ also good as
a research tool. _Every_ content supplier will want research done.

   IMHO, ruling out anything except content-IDs (if insufficiently
obfuscated to be of no interest to DCMA lawyers) is unwise. OTOH,
expecting _any_ particular query to always receive a useful reply
is naive.

> What other sort of information should be a focus of ALTO?

   It would be rather useful to have "characteristics that indicate
congestion" on a path. The applications are going to have to judge
instantaneous congestion anyway, and basing that judgment on
known characteristics rather than guesswork should speed progress
towards an optimal mix.

   Jitter in the latency will be of interest to certain applications.

--
John Leslie <[e-mail]>
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi