![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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