Re: [Tsvwg] Re: terminology issues in draft-floyd-tsvwg-besteffort - flat monthly pricing
dimitri papadimitriou <dpapadimitriou@psg.com> Fri, 27 July 2007 03:22 UTC
Return-path: <tsvwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEGPp-0001le-5h; Thu, 26 Jul 2007 23:22:57 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1IEGPo-0001kr-3P for tsvwg-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 23:22:56 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEGPn-0001ki-OB for tsvwg@ietf.org; Thu, 26 Jul 2007 23:22:55 -0400
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEGPm-0007b9-U4 for tsvwg@ietf.org; Thu, 26 Jul 2007 23:22:55 -0400
Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from <dpapadimitriou@psg.com>) id 1IEGPe-000IPH-EE; Fri, 27 Jul 2007 03:22:52 +0000
Message-ID: <46A96502.1070901@psg.com>
Date: Fri, 27 Jul 2007 05:22:42 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Re: [Tsvwg] Re: terminology issues in draft-floyd-tsvwg-besteffort - flat monthly pricing
References: <5.2.1.1.2.20070726141117.04e7a828@pop3.jungle.bt.co.uk>
In-Reply-To: <5.2.1.1.2.20070726141117.04e7a828@pop3.jungle.bt.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -104.4 (---------------------------------------------------)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc: tsvwg IETF list <tsvwg@ietf.org>, Mark Allman <mallman@icir.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel-lucent.be
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Errors-To: tsvwg-bounces@ietf.org
bob you wrote: "so there won't be sufficient incentives for anyone to invest in more capacity for those of us who want to use the Internet responsibly." this might be indeed a concern but as shorter life socialist ;-) i do also strongly believe that before discussing the solution space we should first within the IETF community at large come with a good, clear, and common understanding whether this is a concern or not, if this is the case how important & urgent it might be, have better understanding about of some of the root causes, etc. -d. Bob Briscoe wrote: > Sally, > > I just realised that I should have added a very important point about > "who controls the choice" to the rather philosophical response below. > > I'm trying to make sure we at the IETF don't have to decide whether the > Internet more favours rich people, malicious people or selfish people. > I'm trying to make it so what you think or what I think about this > doesn't matter (at least any more than what everyone else in the world > thinks). > > Firstly, what I'm proposing would sit alongside the current Internet > (re-ECN packets are distinguishable from non-re-ECN packets, so they > effectively partition all traffic orthogonally to Diffserv). > > Secondly, one partition would be the current Internet, with all its > vulnerabilites to selfish and malicious users as well as all its > strengths. The other partition would be this new proposal where the > market and social governance can control the way the Internet shares out > resources. > > At a grander level, the choice of how much resource each of the two > partitions gets would be under the direct control of ISPs, but in turn > their choices are also affected by the market and perhaps by social > control through government regulation. > > I know this fits your preferred model of how new resource allocation > strategies should be added to the Internet. The question is whether it > is sufficiently important to use IP header space to provide this choice. > We don't need to decide that now, but we do need to debate it widely - > more widely than tsvwg. > > > Bob > > At 18:16 24/07/2007, Sally Floyd wrote: >>> 3/ User pricing: Flat monthly (in our simplest effective proposal). >>> >>> Please don't imply we're advocating user congestion pricing, given >>> the whole reason we brought re-ECN to the IETF back in 2005 was >>> because we found a way to limit congestion without constraining how >>> operators price their services to their customers. Specifically, >>> re-ECN is designed to work with flat monthly pricing. >> >> This draft is not about re-ECN. It is about the usefulness of >> "simple best-effort traffic", and the usefulness of flow-rate fairness >> for simple best-effort traffic. >> >> This draft is not about the presence or absence of flat monthly >> pricing for users. One could have flat monthly pricing with no >> other limitations, one could have flat monthly pricing with volume >> limits, or one could have flat monthly pricing with some form of >> "you get what you pay for". The first two forms don't result in >> "rich" users getting all of the bandwidth in times of high congestion >> (e.g., after the earthquake). The third form easily could. E.g., >> if all of the traffic was "you get what you pay for", even with >> flat monthly fees, then it could be really expensive to send packets >> in the time interval after the earthquake, or some other highly-congested >> period, and only the rich would be able to send packets. I would >> be opposed to setting such a "you get what you pay for" goal as the >> overriding goal for the global Internet, with or without flat monthly >> fees. > > I know. It's distasteful to me to (I am a life-long socialist). But the > alternatives are worse. I have thought about this long and hard. > > On the demand side: If the rich don't get to be able to buy the right to > use capacity, the alternative is that the malicious and selfish get to > drive out those trying to be sociable in their use of the Internet. And > that's for always, not just during earthquakes. Also, the lack of any > resource sharing arbitration will lead to a vacuum that will be filled > by the rich and powerful (which is what deep packet inspection > represents - those with power and influence controlling what can and > can't be done on the Internet). > > On the supply side: The malicious and selfish will use the Internet > excessively, but not pay their share, so there won't be sufficient > incentives for anyone to invest in more capacity for those of us who > want to use the Internet responsibly. > > In summary, a knee-jerk reaction against a market mechanism needs to be > tempered by the thought of what will otherwise fill the vacuum - the > lesson of the Soviet Union? > > However, you will notice in my draft on fairness (and in my design of > re-ECN) that I have been careful to enable more equitable resource > allocation schemes locally. This can give _true_ equality, whereas flow > rate equality is just a license for the selfish and malicious to take > what they want. > > Overall, I put my hands up and admit it: we don't have a better system > for allocating resources on planet scale than a market. I wish we did. > We do have better resource sharing capabilities locally though, and I > want to enable them. > > > Bob > > >> - Sally >> http://www.icir.org/floyd/ > > ____________________________________________________________________________ > > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT plc. > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > > > > > . >
- [Tsvwg] Re: terminology issues in draft-floyd-tsv… Bob Briscoe
- Re: [Tsvwg] Re: terminology issues in draft-floyd… dimitri papadimitriou
- Re: [Tsvwg] Re: terminology issues in draft-floyd… Bob Briscoe
- Re: [Tsvwg] Re: terminology issues in draft-floyd… dimitri papadimitriou
- Re: [Tsvwg] Re: terminology issues in draft-floyd… Bob Briscoe