Hi Vijay, I am not at all talking about reinventing what BitTorrent can do or even remotely about any actual p2p application itself. I am only talking about peer selection. However, I think there is a critical difference between what I view as contributing to peer selection and what the current proposed charter does. Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. This functionality itself is application agnostic and requires an interoperable solution for it to be beneficial. This has nothing to do with content itself; it is purely about sharing information that helps with peer selection. Lastly, as long as this framework is made available, information can be shared among peers on an overlay in a distributed fashion and/or provided by a service provider host. Best regards, Vidya > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@xxxxxxxxxxxxxxxxxx] > Sent: Monday, October 13, 2008 8:50 AM > To: Narayanan, Vidya > Cc: IESG IESG; ietf@xxxxxxxx; p2pi@xxxxxxxx > Subject: Re: [p2pi] WG Review: Application-Layer Traffic > Optimization (alto) > > 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@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf