Narayanan, Vidya wrote:
I am surprised to see that ALTO is being proposed for a WG after the
last BoF concluded with no consensus whatsoever. I think a second
BoF is more appropriate than a WG on the topic at this time. That
said, I do see the need for this work, although I have some comments
on the current direction.
Vidya: Thank you for the feedback. After analyzing your points,
it seems that the charter as written is already conducive to
the important points raised in your review of it (i.e., we may
already be in agreement.)
More inline.
Overall, I think we should work with the notion of an ALTO "service"
rather than specifically an ALTO "server".
Great. I believe that is exactly what the charter does; the
charter talks in terms of an "ALTO service" at many places
(pedantically speaking, the term "ALTO service" occurs eight
times and the term "ALTO server" occurs six.) The ALTO "server"
mentioned in the charter refers to the *host* the client
finally queries (calling it a "peer" is ambiguous; if you have
a specific term to use here instead of "server", please do let
us know.)
The ALTO service may be provided by a server, a cluster of
distributed servers or as a service in an overlay. Although some of
the charter wording talks about a "service" rather than a "server",
there is enough mention of a "server" entity to imply a strict
client-server protocol.
The charter is not meant to imply a centralized architecture, nor to
rule out peer-to-peer implementations of it. The charter simply
mentions a "request/reply" protocol is needed. Whether or not
there is a cluster of ALTO servers or one needs to be decided by
the requirement analysis and subsequent discussions in the WG.
As part of that, I think there are a couple of key things that need
to be addressed here:
- A protocol that allows peers (or ALTO clients) to publish
information about themselves as part of the ALTO service. An example
of such information may be the uplink/downlink bandwidth of the
peer.
We have had discussions on the mailing list about this already.
Some people felt that providing uplink bandwidth would not be
a good idea for various reasons running from privacy concerns
to peers skewing traffic in favor of a high uplink bandwidth.
Others felt that even if a peers uplink bandwidth was not
provided, it could calculated nonetheless by other peers. That
is, there are degrees of disagreement here and consequently,
including a contentious point in the charter would be counter-
productive.
- The ability to register information types with IANA and extend
these.
Having a IANA registry for the information type carried in the
protocol is certainly a possibility the charter does not rule
out, no?
The request/response protocol should be a generic enough container
for any information that peers can provide and look for, plus what
may be available from service providers, etc. There may be some
guidelines on how such information types can be registered and we may
start with default ones.
Exactly; this is what the charter is saying in the paragraph:
- 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 extensions to the charter
once the work for the initial services has been completed.
We *are* starting with the default information; as other information
is required, we can extend the charter, right? Extending the
charter is cheap -- it is a bureaucratic process that will auto-
matically happen if there are enough interested parties willing to
do the work and the work is considered to be important enough.
I believe that the higher bar is ensuring that the initial charter
contains the right amount of work so that the WG can finish it
in an appropriate amount of time.
The Working Group will design and specify an Application-Layer
Traffic Optimization (ALTO) service that will provide applications
with information to perform better-than-random initial peer
selection. ALTO services may take different approaches at balancing
factors including maximum bandwidth, minimum cross-domain traffic,
lowest cost to the user, etc. The WG will consider the needs of
BitTorrent, tracker-less P2P, and other applications, such as
content delivery networks (CDN) and mirror selection.
What does the above sentence mean? If we are putting such a list
together, we must also take into account needs from structured P2P
overlays such as those being specified in P2PSIP.
In P2PSIP, the amount of information being stored in the overlay
is small (a R-URI, on the order of tens of bytes.) ALTO will
not much help there. OTOH, ALTO will help tremendously if in
a P2PSIP network, there is a need to find a peer that hosts the
recording of a 2-hour conference call. Nothing in the ALTO
charter prevents this from happening as it is specified today.
Is this meant to allow for entities such as proxies to be in the
path?
There's been quite a lot of discussion on this topic on the list.
Current consensus is to keep the architecture as simple as
possible and exclude at least initially support for non-transparent
intermediaries; if at some point we have evidence of the need
for it, the group will go through rechartering.
Earlier, it is mentioned that the requirements document will
determine the types of information that are useful for P2P
applications. Given that, it seems premature to conclude that the WG
should consider the above mentioned parameters. Also, as I
mentioned earlier, I think it is essential to keep the protocol and
message formats extensible and allow for exchange of any registered
information type.
The limit on what data to consider initially was suggested to
avoid the group to wander for years discussing any kind of
possible information; however, extensibility will be the key
principle in designing a protocol (for good design practices
rather than because it is written in the charter).
Another question I have is about the assumptions around expected peer
addressing models. Some of the above seems to hint at IP addresses
- is this an assumption already?
No, the text says "ranked lists of the peers requested by the
client" exactly because we still don't know how they could be
identified.
- In order to query the ALTO server, clients must first know one or
more ALTO servers that might provide useful information. The WG
will look at service discovery mechanisms that are in use, or
defined elsewhere (e.g. based on DNS SRV records or DHCP options).
If such discovery mechanisms can be reused, the WG will produce a
document to specify how they may be adopted for locating such
servers. However, a new, general-purpose service discovery
mechanism is not in scope.
Alternately, the clients may look for ALTO services within an
overlay. This can be modeled as service discovery within the overlay
- I'm, however, not suggesting that we take on solutions for that.
OK, good; we do not want to bite more than we can chew. If a
suitable overlay service discovery mechanism exists, we will
happily use it.
When the WG considers standardizing information that the ALTO
server could provide, the following criteria are important to
ensure real feasibility.
- Can the ALTO service technically provide that information?
- Is the ALTO service willing to obtain and divulge that
information?
- Is it information that a client will find useful?
I'm not sure how useful it is for us to answer this question. The
protocol we develop simply needs to be a container for any
information that has a registered type and fits a certain format.
Sure, no disagreements here. However, the list of questions
that appears in the charter was suggested as a set of minimum
vetting points to ensure that the WG spent some thought process
on making an adequate determination on the importance and use
of an ALTO service. The list of questions does not inhibit
the protocol we develop in any way.
If we can build an extensible protocol, we don't need to define all
possible kinds of information that get carried in it.
Please see above.
Thank you.
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg(_at_){alcatel-lucent(_dot_)com,bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf