Vidya: Thank you for your response and your time in helping
define the work. More inline.
Narayanan, Vidya wrote:
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.
I think the disconnect we may be having is that you view
ALTO as a peer description protocol; it is not. Other
protocols like BitTorrent, for example, are more suited to
this, and they do exactly what you want. In a BitTorrent
overlay (swarm), the overlay knows exactly which peer is
contributing which content, which peer has which chunks,
the download/upload ratio, the time the peer joined the swarm,
whether the peer is choked or unchoked, whether the peer has
a public port, etc. ALTO is not out to replace BitTorrent. What
ALTO is providing are better strategies for peer selection.
For instance, it is not ALTO that gets to decide which peer is
hosting which content and what the contributions of that peer
to the overlay are. However, it is ALTO's job to provide
information to a querying peer allowing it to determine wisely
where it will download the content from.
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 far, no one on the list has proposed that ALTO be a peer
description and publication protocol. So based on the discussion
we have had since (essentially the workshop in) May 2008 on the
p2pi list, I would hesitate to add in the charter something that
participants have not expressed any preference for (i.e., a
deliverable on peers publishing their information.)
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.
I am confused; I thought earlier you were trying to make the case
that ALTO should provide even more specific information that
needs to be published?
In the end, we do agree on that any protocol be extensible. Whether
that is extensible through a registry-like mechanism or other
means remains to be discussed in the WG, right?
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 :)
Protocols evolve, networks evolve. I am sure we were prescient
when we designed TCP such that HTTP could simply use it. However,
other realities of evolution did force us to design SCTP, for
instance. But regardless, the point is that we should be general,
and we are; but we have to do this while drawing a fine line
between research and engineering. Some applications that are
appearing on the horizon are streaming media and P2PTV; for
these we have opened up channels with IRTF. So I don't see
where we are constraining ourselves in ALTO.
I can envision video applications using the P2PSIP framework, for
instance.
Yes, and as I wrote earlier, they can use ALTO to discover the
the peer they find optimal within their constraints and use it.
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?
Look at the Ono work, which is a plug-in to BitTorrent. It
uses Akamai redirections to find the closest peer to download
content from. In a sense, ALTO is replacing that ad-hoc
lookup and providing a much more deterministic answer. That
is what we mean by the needs of "BitTorrent/CDN etc."
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.
But we are not. As I made the point earlier, ALTO is not out to
replace BitTorrent. So replicating in ALTO the details about
peers that BitTorrent already has is counter-productive. Instead,
ALTO can focus on providing the pieces that BitTorrent does not:
topology, policy, etc. That is where we will make a difference.
Thanks,
- 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