Re: [Tsvwg] Re: terminology issues in draft-floyd-tsvwg-besteffort - flat monthly pricing

dimitri papadimitriou <dpapadimitriou@psg.com> Tue, 31 July 2007 08:46 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 1IFnNJ-0007dt-Hl; Tue, 31 Jul 2007 04:46:41 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1IFnNI-0007do-9m for tsvwg-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 04:46:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnNI-0007dg-0A for tsvwg@ietf.org; Tue, 31 Jul 2007 04:46:40 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFnNG-0005u9-QM for tsvwg@ietf.org; Tue, 31 Jul 2007 04:46:39 -0400
Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from <dpapadimitriou@psg.com>) id 1IFnN8-0007Ir-A0; Tue, 31 Jul 2007 08:46:36 +0000
Message-ID: <46AEF6DC.2080104@psg.com>
Date: Tue, 31 Jul 2007 10:46:20 +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> <5.2.1.1.2.20070726141117.04e7a828@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070730181738.04a1c4b8@pop3.jungle.bt.co.uk>
In-Reply-To: <5.2.1.1.2.20070730181738.04a1c4b8@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: 31b28e25e9d13a22020d8b7aedc9832c
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,

see in-line

>> 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.
> 
> I've been working in non-IETF fora where that issue has been debated for 
> some years. That would be difficult for the IETF to do. It's difficult 
> for economists to come to any conclusion on that issue. Partly because 
> it gets convolved with monopoly issues in access networks.

since you are trying to address a non technical problem with a technical 
solution, there is a need for:
- determining whether this is a concern that the ietf is willing to
   address
- understanding root causes and effects and how penalizing they are
- the impact of the various mechanisms that could be put in place to
   solve the issue(s)
- whether the proposed solution really solves the problem for which they
   have been defined (reliability) and whether the cure is not worse
   than the disease itself (side effects)

all these point deserve imho a much better documentation that what's 
available and necessary in order to progress such effort

> But in my view, the problem is a lot more basic - in the current 
> Internet architecture there isn't even the basics of a mechanism to 
> support resource allocation: accountability. That sounds like billing, 
> but that's not what I mean. I mean being able to attribute a cost to a 
> user or network (irrespective of what you do with the information).

per rfc 2828, accountability is the property of a system or a service
(including all of its system resources) that ensures that the actions of
a system entity may be traced uniquely to that entity, so that it can be
held responsible for its actions.

in the present case, i think you are referring to the process where
users would be accountable for the openly accessible internet resources
they are making use of

the main technical point is fairness rules & enforcement on responsible 
internet's resources usage (outside of any market,business or economical 
pressure)

> It would be equivalent to a supermarket not being able to tell who had 
> taken stuff off the shelves. I think most economists would agree that 
> lack of accountability removes most incentives to invest if demand 
> doesn't easily satiate (e.g. a provider has the incentive to keep 
> investing in supplying all-you-can-eat buffet to people with limited 
> stomach capacity, but if faced with a range of customers with huge 
> stomachs, they tend to find other ways to limit demand - e.g. one plate 
> each).

hence, your concern is to limit the demand for economical reasons

mine, is to avoid starvation that could result if too big stomachs are 
present at the same time for societal reasons

hence, you see that one may have multitude of causes, different 
motivations, multiple approaches to the problem and a set of resulting 
solutions, all these points deserve much better analysis in my opinion

-d.

> Bob
> 
> 
>> -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
>>>
>>> .
>>
>> ____________________________________________________________________________ 
>>
>> Bob Briscoe, <bob.briscoe@bt.com>      Networks Research Centre, BT 
>> Research
>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 
>> 645196 
> 
> 
> 
> .
>