[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