Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs



Ted Hardie wrote:
> At 3:15 PM -0700 6/2/08, Enrico Marocco wrote:
>> It seems to me that this turned out to be a two-sided problem.  On the
>> one hand, it is clear that applications on the endpoints are in the
>> worst position to make optimal network decisions; a first part of the
>> solution should thus consist of a mechanism to defer such decisions to
>> external entities
> 
> Of course you can recast this  as "So we should make sure that
> there are mechanisms that allow them to make more optimal decisions.
> The facilities which provide this information need not be controlled
> by the ISPs, but might be third party services which indicate
> cost/topology/congestion or some profile mix of the three."

Existing systems today used (or proposed) for optimizing peer selection
use different methods to make their choices.  While it would be easy to
define a common interface such systems could expose to p2p applications,
it would be probably hard to standardize cost/topology/congestion/policy
notification mechanisms in order to accommodate all different approaches
adopted by existing and foreseeable solutions.

Examples of existing systems are Vivaldi and Ono, embedded in 10^5~10^6
Azureus clients out there, P4P, iPlane, PIC and many others, simulated
and emulated in friendly environments.

> To my way of thinking, that makes it easier to consider the API
> design, as it is not so much an API that says "What's the best
> choice right now?"  but "What's the best X (flow pattern, topology,
> price)".  The second set of questions is sufficiently more modular
> that it is both easier to get right and, at least in my opinion,
> more interesting.

Well, I'd probably prefer a compromise between the two, something like
"What's the best choice for downloading X Mb of delay-sensitive data?".
And, just to be clear, available options must be provided by the
application which, at the end of the day, will be also in charge of
making the final decision (including ignoring the answer if for some
reason it doesn't like it).

-- 
Ciao,
Enrico

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.