Narayanan, Vidya wrote:
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.
Vidya: Thank you for your response. I think we are converging
to the crucial difference in this thread. This is a good thing.
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.
I believe that incorporating (b) expands the charter quite a bit,
whereas the consensus since the first BoF was for narrowing
it down. I will also note that the feedback expressed on the
list does not appear to view ALTO as a peer description protocol.
To be sure, I am not unsympathetic to (b), it seems like a great
problem to solve, it's just that ALTO may not be the best place
to solve this problem.
In the end, maybe the ADs can decide a way forward.
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.
Protocols like BitTorrent already contain elements such that
the peers know enough about other peers that the overlay is
functioning. The information that BitTorrent (and other P2P
overlays) do not have is topology and policies. This is where
ALTO is urged to fill a crucial gap, at least initially.
Since the IETF/MIT workshop, the problem outlined for what has
become ALTO has been how to choose the peers wisely. We (i.e.,
the BoF/list participants) have been diligent to note that
ALTO is not completely dependent on service providers; third
parties can run ALTO servers as well; and these servers can use
ad-hoc techniques like Ono (which was discussed yesterday on
the list) or some form of Internet Coordinate Systems to derive
a topology. We have also been diligent to note that ALTO is an
additional service provided to an overlay; the overlay will
continue to function without it (albeit in a bit of a sub-optimal
manner.) We have also noted given a choice between a service
provider run ALTO server and a third party ALTO server, that
peers will naturally gravitate towards the ALTO server
that provides them the best information over a long period
In other words, we have covered substantial grounds since
the IETF/MIT workshop and the Dublin BoF based on the
premise of the problem as the group has understood it.
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Ietf mailing list