Re: [p2prg] New version of p2prg-mythbustering

Matthew Kaufman <matthew@matthew.at> Mon, 13 July 2009 16:58 UTC

Return-Path: <matthew@matthew.at>
X-Original-To: p2prg@core3.amsl.com
Delivered-To: p2prg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D610528C19B for <p2prg@core3.amsl.com>; Mon, 13 Jul 2009 09:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.43
X-Spam-Level:
X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 lGMh00G78lmr for <p2prg@core3.amsl.com>; Mon, 13 Jul 2009 09:58:07 -0700 (PDT)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by core3.amsl.com (Postfix) with ESMTP id 278DF28C4D4 for <p2prg@irtf.org>; Mon, 13 Jul 2009 09:58:07 -0700 (PDT)
Received: from [10.10.155.2] (unknown [10.10.155.2]) by where.matthew.at (Postfix) with ESMTP id E1D4914806A; Mon, 13 Jul 2009 09:58:30 -0700 (PDT)
Message-ID: <4A5B67B6.40101@matthew.at>
Date: Mon, 13 Jul 2009 09:58:30 -0700
From: Matthew Kaufman <matthew@matthew.at>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Ray.Bellis@nominet.org.uk
References: <OF0B76E4E5.7F557F12-ON802575F2.0057FF67-802575F2.00584D44@nominet.org.uk>
In-Reply-To: <OF0B76E4E5.7F557F12-ON802575F2.0057FF67-802575F2.00584D44@nominet.org.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: p2prg@irtf.org
Subject: Re: [p2prg] New version of p2prg-mythbustering
X-BeenThere: p2prg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: matthew@matthew.at
List-Id: Peer-to-Peer Research Group <p2prg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/p2prg>
List-Post: <mailto:p2prg@irtf.org>
List-Help: <mailto:p2prg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2009 16:58:07 -0000

Ray.Bellis@nominet.org.uk wrote:
> Have you considered the case where the ISP might prefer *that their 
> users *not** localise the traffic?
>
> The dominant wholesale xDSL technology in the UK is BT's IPStream 
> product. All customer traffic is backhauled via L2TP to the ISP's 
> network (almost always to London telehouses) and no geographic 
> localisation is possible.
>
> This means that two neighbouring customers of the same ISP are no 
> closer in network terms than two customers at opposite ends of the 
> country.
>
> Why this is particularly significant for UK ISPs is that BT's IPStream 
> backhaul product ("BT Central") is typically 10 times more expensive 
> than global IP transit. Currently BT charge at least £100 per Mbps 
> pcm, whereas volume IP transit can be had for £10 per Mbps or even less.
>
> If two customers mutually exchange traffic at 1 Mbps continuously 
> it'll cost the ISP £200 per month.  If one of the parties is off-net 
> it'll only cost them £110.
>
> Hence IMHO for most UK ISPs it's better for their leeching customers 
> to be getting their data from a neighbour that's **not** on the same 
> network.
This is the extreme case of the much more common "I would prefer to 
export this traffic via free peering than to transport it to one of my 
own customers on the other side of the country" case.

Matthew Kaufman

ps. As someone who's designed nationwide ISP networks several times, 
I've often wondered why consumer ISPs care so much about uploaders. Once 
you've got the traffic out of the end-link multiplexing (which of course 
you can trivially manage) you are either handing it to another ISP you 
peer with, or sending it to a transit provider over a circuit that 
you've bought as symmetric full-duplex bandwidth but which (as you're a 
consumer ISP) you mostly use the downstream side of, both of which have 
zero incremental cost. Unless of course you have the misfortune of a 
user who manages to find someone on your network to send the data to.