I would offer it is important to have the client specify what it thinks is important. However, I would also offer it would be fatal to have "Profile B", "Profile N", "Profile S" selection algorithms, where B, N, and S are different applications. I will guarantee that by the time we're done in the IETF, no one will case about those applications and will have moved on to some other, hot applications.

It may be worth noting what parameters are important.

On Feb 10, 2009, at 7:25 AM, stefano previdi wrote:


On Feb 10, 2009, at 12:43 PM, Song Haibin wrote:

I think it is necessary to discuss whether we need to standardize different peer selection algorithms according to different types of applications.

We may want the alto protocol to allow the requester to specify which type of ranking/preference it needs. Note that this doesn't mean we need to standardize any algorithm.

s.


Best Regards,
Haibin
Email: [email protected]
Skype: alexsonghw


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Enrico
Marocco
Sent: Tuesday, February 10, 2009 7:16 PM
To: Zoran Despotovic
Cc: [email protected]
Subject: Re: [alto] differences among applications

Zoran Despotovic wrote:
I was wondering if and how IETF would address possible differences among relevant P2P applications in the sense that different applications may require totally different solutions. Was there any discussion on this
before on the list?

Yes, there's been some discussion about how to deal with the fact that
different applications may have different requirements for peer
selection -- e.g. file-sharing would benefit most from connections to
peers with higher uplink bandwidth, while realtime communications
applications would probably want to chose media relays with the smallest
delay.

I remember someone suggested that a way to address it could be to simply
provide a means for the querying peer to specify what parameters it
would like to have optimized (delay, bandwidth...) and let the ALTO
server use such information in its processing. However, AFAIK, no
solution proposals at this time do anything like that.

--
Ciao,
Enrico

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to