I'd like to second this, and also make sure that the relationship between ALTO 
and the application is clear.

>From the application perspective, ALTO is a source of useful guidance (i.e. 
>network topology and "cost" model) that can help the p2p network find good 
>peers to connect. But once peers are exchanging data, the p2p network/protocol 
>(and TCP) pretty much takes over, because those protocols address the actual 
>throughput between peers, real-time congestion, etc., that are not addressed 
>by ALTO.

I should also make clear that ALTO does not (and cannot) control the p2p 
network. Generally ALTO guidance should provide better than average peer 
connections (which is certainly what we saw in the P4P field tests), so the p2p 
networks will be motivated to use ALTO guidance when they can because it's in 
their interests to do so. But there will always be cases that are exceptions. 
For example, if a p2p network is getting fantastic data delivery between two 
peers, it is highly likely to keep using that connection no matter what ALTO 
says. And, on the flip side, if the ALTO-recommended peer connections aren't 
providing the data needed, the p2p network will use other peers as data 
sources. And, of course, p2p networks must continue to operate where ALTO 
guidance is unavailable. :-)

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Song Haibin" <[EMAIL PROTECTED]>
To: "Vijay K. Gurbani" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], "IESG IESG" <[EMAIL PROTECTED]>, ietf@ietf.org
Sent: Tuesday, October 14, 2008 4:29:30 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Hi Vijay,

>Narayanan, Vidya wrote:
>> 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.

Totally agree.

>> 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.)

IMHO, not every type of information can be carried in the ALTO protocol, but
only network policy and topology related (e.g. peer preference) information
is allowed. I don't think we are designing BitTorrent here.

Regards!
Song Haibin


_______________________________________________
p2pi mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to