> > Not all of the information is mandatory, but we might consider a
> > mandatory and an optional set.
> >
> > Do we have this in the current requirements? I think this is very
> > important.
>
> When we were working on the charter definition, we were (luckily)
> prescient enough to recognize that different applications will
> have different requirements. To that extent, I do want to
> point out the following from our charter:
>
> - A document defining core request and response formats
> and semantics to communicate network preferences to
> applications. Since ALTO services may be run by entities
> with different level of knowledge about the underlying
> network, such preferences may have different representations.
> Initially the WG will consider: IP ranges to prefer and
> to avoid, ranked lists of the peers requested by the client,
> information about topological proximity and approximate
> geographic locations. Other usages will be considered
> as charter additions once the work for the initial services
> has been completed.
How broad is the understanding of "information about
topological proximity and approximate geographic locations."?
Latency might be included, but bandwidth doesn't sound like it's
a characteristic of topological proximity or geography.
Maybe an ALTO server must understand and be able to respond
with {whatever data set we decide}, but whether any given
field is used is a local policy decision: you can always ask me for
topological data, but I can always answer "None of your
business." That also promotes rapid deployment--an ISP can
roll quickly even if it only has one datum.
If I understand where we are now, there are two possible query
sets from a client:
Q: "Here's a list of potential peers, please rank them."
A: p1, p2, p3, ... pn
Q: "Send me a list of network prefixes with relative
preferredness."
A: 300,000 entries from routing table with forwarding information
abstracted.
In the first instance, as long as the number of peers is limited, I can
imagine the client asking the server to customize the response based
on client (application) preferences, e.g., "Please weight packet loss
as an important consideration." Of course, the server operator can
set weights per policy or ignore the requested ranking, but that may
be a feature of a specific implementation and not explicit in the
protocol definition.
In the second instance, there's a potential scaling problem,
depending on the level of data provided. The server will not
be able to sort 300k entries according to the client's relative
priorities. It also seems to me that much of the data useful for
decisions is only available for individual potential peers:
Function
Attibute Rank pot. peers Pref'd prefixes
latency, yes yes
cost yes yes
bandwidth, yes no
packet loss, yes no
reliability, yes no
time sensitivity, yes no
burstiness, yes no
Even latency, though, would be relative to the ALTO server, not
the ALTO client.
Responding to multiple subthreads in one message, but I thought
it would be more efficient this way.
Lee
P Go Green! Print this email only when necessary. Thank you for helping Time
Warner Cable be environmentally responsible.
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
