[p2pi] ietf mandate ...
"Don Bowman" <don@sandvine.com> Sun, 08 June 2008 18:28 UTC
Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5263A6A8B; Sun, 8 Jun 2008 11:28:10 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1393A6911 for <p2pi@core3.amsl.com>; Sun, 8 Jun 2008 11:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3elOjSMsM+IS for <p2pi@core3.amsl.com>; Sun, 8 Jun 2008 11:28:08 -0700 (PDT)
Received: from gw.sandvine.com (unknown [199.243.201.138]) by core3.amsl.com (Postfix) with ESMTP id 065633A6AE5 for <p2pi@ietf.org>; Sun, 8 Jun 2008 11:28:07 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 08 Jun 2008 14:28:22 -0400
Message-ID: <EB618291F3454E4DA10D152B9045C017014CB24B@exchange-2.sandvine.com>
In-Reply-To: <mailman.5529.1212912021.4906.p2pi@ietf.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ietf mandate ...
Thread-Index: AcjJPcFPZHhrtek+QSeBfukW3GULQQAVUPzQ
References: <mailman.5529.1212912021.4906.p2pi@ietf.org>
From: Don Bowman <don@sandvine.com>
To: p2pi@ietf.org
Subject: [p2pi] ietf mandate ...
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org
One of the questions we left unanswered was what, if anything, the ietf should do to be involved. Since the ietf is a technical standards body, rather than a political or legal, that contrains the area 'somewhat' :) personally I have a real problem with the idea of 'flow destination selection signalled from the network for times of congestion or locations of cost', I think that it will be very hard, these things change dynamically (mobile ip, load, network failovers, ospf changes, ...). Thus I am not a fan of trying to build the 'best cost path' approach (despite having designed and deployed Product at large scale that did this)... although its pragmatic For certain classes of network, its not a generic solution. I really like the idea of a true scavenger class. It would hugely incent ISP's and operate in the best interest of the users of the network. People could have a 'quota' that they purchased as part of their plan, and choose to spend their credits on each packet according to its delivery guarantees. Any packet they didn't wish to 'pay for' would go in scavenger. The implementation of a true end-to-end scavenger class is quite hard, when placed into network designs that have properties like: * L2 (ATM, MPLS, ...) that don't look @ DSCP mark * overlay networks that priortise the overlay rather than the Packets within * access equipment that doesn't look @ packet priority * dynamic bandwidth access networks such as WiMax, 3GPP So this is an area a standard's body could invest additional (I'm aware of the considerable efforts thus far) effort. Another idea which might have merit is the use of 'anycast' With ipv6 it would be economic to assign an ipv6 anycast IP to each unique piece of content, and on a packet-by Packet basis (e.g. SCTP? UDP?) obtain it from the 'closest' location, even as you or the destination moved around a mobile ip Network. I realise this is a proposed implementation, but Maybe forget the method... I think TCP is just the incorrect transport to get content from many locations that offer the same thing, when the transfer might be long in duration and high in cost. For this to work, a fairly dynamic directory service (think DDNS w/ huge update rates) would be pretty cool. Its kind of similar to the problem of allocating a new Multicast group address, world-wide. The 'anycast' addressing scheme would lend itself well to access ISP who had a higher cost of upstream than downstream (e.g. WiMax, Cable, 3G), or ones which had a higher cost of transit than access (e.g. island nations) as they could more easily deploy caching. So maybe a standard which allowed: * allocation of 'l3 address' <-> content * scavenger-aware connectionless, guaranteed transport to dynamic l3 endpoints Would be pretty cool. It would align a lot of 'non-technical' interests too. The issue of user-to-user fairness w/in the scavenger class would be left to the ISP to enforce in some fashion, either economically or technically or not at all. _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
- [p2pi] ietf mandate ... Don Bowman
- Re: [p2pi] ietf mandate ... Robb Topolski
- Re: [p2pi] ietf mandate ... Don Bowman
- Re: [p2pi] ietf mandate ... Livingood, Jason
- Re: [p2pi] ietf mandate ... Nicholas Weaver
- Re: [p2pi] ietf mandate ... Robb Topolski
- Re: [p2pi] ietf mandate ... Robb Topolski