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
- To: Enrico Marocco <enrico.marocco at telecomitalia.it>, Laird Popkin <laird at pando.com>
- Subject: Re: [p2pi] Thoughts on how IETF standards can help P2P/ISPs
- From: Ted Hardie <hardie at qualcomm.com>
- Date: Mon, 2 Jun 2008 16:06:03 -0700
- Cc: "ramit at pando.com" <ramit at pando.com>, "p2pi at ietf.org" <p2pi at ietf.org>, "p4pwg at yahoogroups.com" <p4pwg at yahoogroups.com>
- Delivered-to: ietfarch-p2pi-web-archive at core3.amsl.com
- Delivered-to: p2pi at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie at qualcomm.com; q=dns/txt; s=qcdkim; t=1212447968; x=1243983968; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p06240606c46a2c26d09d @[129.46.226.27]>|In-Reply-To:=20<484470F1.7000105 at teleco mitalia.it>|References:=20<1865369468.307061212422766942. JavaMail.root at dkny.pando.com>=0D=0A=20<484470F1.7000105 at t elecomitalia.it>|Date:=20Mon,=202=20Jun=202008=2016:06:03 =20-0700|To:=20Enrico=20Marocco=20<enrico.marocco at telecom italia.it>,=0D=0A=20=20=20=20=20=20=20=20Laird=20Popkin =0D=0A=09<laird at pando.com>|From:=20Ted=20Hardie=20<hardie @qualcomm.com>|Subject:=20Re:=20[p2pi]=20Thoughts=20on=20 how=20IETF=20standards=20can=20help=20P2P/ISPs|CC:=20"ram it at pando.com"=20<ramit at pando.com>,=20"p2pi at ietf.org"=20<p 2pi at ietf.org>,=0D=0A=20=20=20=20=20=20=20=20"p4pwg at yahoog roups.com"=20<p4pwg at yahoogroups.com>|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcA fee=3Bi=3D"5200,2160,5308"=3B=20a=3D"3449316"; bh=d/q84JicNtRvNsHtVouyymM8UHnb7l1iJGwRuF2xiJA=; b=OrhFTvouiCzy5lVzUMaupmYqb8eDuoGNIBRaENasAcBO61yH2eZnuOyv h/BWlVJaxvKcjsAXexH+wThv+59nqHlag0HmmuGJXxvBCDIv72HPBAC+R qCxM89Ar0zM5/EAKAJ0Mbrc+pLA56Jf3TQn/roCSVg01O/DGVl+viP8l4 A=;
- In-reply-to: <484470F1.7000105@telecomitalia.it>
- List-archive: <http://www.ietf.org/pipermail/p2pi>
- List-help: <mailto:p2pi-request@ietf.org?subject=help>
- List-id: P2P Infrastructure Discussion <p2pi.ietf.org>
- List-post: <mailto:p2pi@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
- References: <1865369468.307061212422766942.JavaMail.root@dkny.pando.com> <484470F1.7000105@telecomitalia.it>
- Sender: p2pi-bounces at ietf.org
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
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.