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

[Ted Hardie <[e-mail]>]

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

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.

Just  my two cents,
				Ted


>(not necessarily controlled by ISPs, as e.g. in the
>case of Ono, where the redirection service is provided by Akamai
>servers). The need for such a mechanism was claimed by several papers
>[4,26,28,29] and, AFAIR, received little objection (the one that I
>recall was the "hot potato" thing, where the external entity providing
>the peer selection service would be able to place sort of DDOS attacks
>against specific targets/networks).
>
>On the other hand, how to compute best paths is a separate part of the
>problem; topology/cost/congestion notification, cache identification,
>usage metrics, and the like all fall in this category and, at this time,
>are probably more research topics than engineering issues.
>
>Right now, I think the IETF should focus on the first part of the
>problem, the front-end of a generic third-party peer selection service
>p2p applications can query in order to make better choices; innovation
>and competition will then happen on the back-end of such a service
>without requiring standardization in the first place.
>
>[*] References at
>http://www.ietf.org/mail-archive/web/p2pi/current/msg00005.html
>
>--
>Ciao,
>Enrico
>
>Content-Type: application/x-pkcs7-signature; name="smime.p7s"
>Content-Description: S/MIME Cryptographic Signature.p7s
>Content-Disposition: attachment; filename="smime.p7s"; size=3504;
>	creation-date="Mon, 02 Jun 2008 15:26:25 GMT";
>	modification-date="Mon, 02 Jun 2008 15:26:25 GMT"
>
>Attachment converted: Macintosh HD:smime 1480.p7s (    /    ) (007B339F)
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=191;
>	creation-date="Mon, 02 Jun 2008 15:26:25 GMT";
>	modification-date="Mon, 02 Jun 2008 15:26:25 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 1846.txt (TEXT/ttxt) (007B33A0)

_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi