Hi Vijay,
Thank you for your response. Please see comments inline below.
-----Original Message-----
From: Vijay K. Gurbani [mailto:vkg(_at_)alcatel-lucent(_dot_)com]
Sent: Friday, October 10, 2008 11:41 AM
To: Narayanan, Vidya
Cc: IESG IESG; ietf(_at_)ietf(_dot_)org; p2pi(_at_)ietf(_dot_)org
Subject: Re: [p2pi] WG Review: Application-Layer Traffic
Optimization (alto)
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.)
When we consider ALTO as a distributed service, there may not necessarily be
"a" host that specifically resolves the ALTO queries. For instance, consider
the case where ALTO is a service offered in an overlay. There may be peers
publishing information about themselves on the overlay and other peers looking
up such information. These are not necessarily client-server style
communications. In fact, all that is important in this context is that the
overlay acts as a rendezvous for sharing such information. Now, of course,
that is one possible model. But, in order to allow for that and other models,
I do want the charter to keep the focus on the service and not on a server.
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.
I'm afraid that would be a mistake. It actually doesn't matter if we don't
agree today on the exact types of information that can be shared. It is
important that we have a protocol that allows peers to publish ALTO related
information. Having this protocol be extensible would allow for any type of
information to be carried in it. So, I strongly believe we don't need a
recharter to consider any information types - in fact, I'd be okay if this
effort only took on the protocol and if all information types were to be
registered through other means. That said, I'm not against taking on some
subset of those types - I don't believe that should be the core focus of this
work though.
- 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?
Well, it is a bit hard to say what the charter does not rule out - typically we
try and do what the charter says we should do. However, before we get to the
registry, we need to agree on the protocol components. In my view, there are
two such components - the publish protocol mentioned above and the
request/response protocol (actually, more generically, a lookup protocol)
mentioned below.
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?
Actually, I am saying that is exactly what is not needed. I don't see the
information types as something this effort will necessarily nail down. We need
to define interoperable semantics for the protocol - what gets carried in it
may actually be registered as a type in the registry outside of this effort.
The registry comes into picture for enabling this part.
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.
I would like us to think beyond applications we see today. Had TCP not been
designed that way, we probably would have needed a redesign of it for HTTP :)
I can envision video applications using the P2PSIP framework, for instance. In
any event, I still don't have a good understanding of what it means to consider
the needs of these various things - what does it mean to say that we'll
consider the needs of BitTorrent/CDN, etc.? Could you maybe give me an example
of what it means?
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.
Okay.
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).
Again, as I wrote above, I think the information types are less important than
the container for any such type in the protocol.
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.
Hmmm... Okay. Perhaps it would be good to say that some analysis is needed to
determine how to identify the peers? Maybe this is something that needs to
happen in the requirements phase.
<snip>
- 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.
What I am saying is that it is not for us to determine the usefulness of a
particular piece of information. As long as the peers or service providers are
willing to share a piece of information, that can be consumed by other peers as
they deem fit. So, I don't think we should consider ourselves the gatekeeper
for the types of information shared.
Best regards,
Vidya
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf