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

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Wed, 01 August 2007 03:10 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 1IG4bD-00013D-I2; Tue, 31 Jul 2007 23:10:11 -0400
Received: from tsvwg by megatron.ietf.org with local (Exim 4.43) id 1IG4bC-00012x-J7 for tsvwg-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 23:10:10 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG4bC-00012o-7X for tsvwg@ietf.org; Tue, 31 Jul 2007 23:10:10 -0400
Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG4bA-0007J7-Sg for tsvwg@ietf.org; Tue, 31 Jul 2007 23:10:09 -0400
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 04:10:07 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 04:10:07 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1185937805843; Wed, 1 Aug 2007 04:10:05 +0100
Received: from mut.jungle.bt.co.uk ([10.86.0.1]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l7139xLU016206; Wed, 1 Aug 2007 04:10:03 +0100
Message-Id: <5.2.1.1.2.20070801031129.04a4ddb0@pop3.jungle.bt.co.uk>
X-Sender: rbriscoe@pop3.jungle.bt.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
Date: Wed, 01 Aug 2007 04:09:59 +0100
To: dpapadimitriou@psg.com, dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel-lucent.be
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Subject: Re: [Tsvwg] Re: terminology issues in draft-floyd-tsvwg-besteffort - flat monthly pricing
In-Reply-To: <46AEF6DC.2080104@psg.com>
References: <5.2.1.1.2.20070730181738.04a1c4b8@pop3.jungle.bt.co.uk> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: -1.36 () ALL_TRUSTED
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 01 Aug 2007 03:10:07.0210 (UTC) FILETIME=[767D1CA0:01C7D3E9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d16ce744298aacf98517bc7c108bd198
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
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

Dimitri,

At 09:46 31/07/2007, dimitri papadimitriou wrote:
>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

I agree. Many people have now clocked that there is probably a big problem 
here, but no-one (including me) has really quantified the problem, or the 
likely impact of the proposed solution (tho I have tried to _characterise_ 
the likely impact of my proposed solution in terms of how I expect the 
Internet might evolve).

I have an idea how to create a model to comapre the Internet with and 
without, and I've started a new research activity here in BT to quantify 
the problem at least by delivering a model and allowing people to see what 
the impact would be if they plug in assumptions that they believe are valid.

But, as the guy at this URL says:
<http://paperpicker.wordpress.com/2006/12/21/dismantling-a-religion-is-tcp-wrong/>
"It would be nice to see a simulation illustrating the difference, but that 
does not have to be Briscoe's job, of course. It is the networking research 
community who should react."


>>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.

Yes. The solution I have proposed actually makes a leap here - it moves 
information about the effect of the entity's action towards the entity, 
rather than identifying the entity where its effect is felt.

>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

Exactly

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

That's not really the main technical point, which as you rightly point out 
is primarily about accountability. Fairness enforcement and better fairness 
are likely outcomes of accountability. They are secondary effects, that I 
predict will happen because of the invisible hand of economics - if we only 
had accountability. IOW, my tract on fairness was my attempt to answer your 
third bullet - on what impact there will be from introducing accountability.


>>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

That's not a good characterisation. My concern is to ensure either demand 
shrinks or supply grows - whichever users want. I certainly don't want to 
limit demand if it is true demand (rather than just desire or whim).

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

I would share with your concern (and Sally's) if I was proposing congestion 
pricing to end-users. But I don't believe congestion pricing will be common 
at all. I've proposed bulk per-user token bucket policers 
<draft-briscoe-tsvwg-re-ecn-04.txt>, which prevent small stomachs being 
starved except for short periods. I've also shown (in a paper on the likely 
impact on DDoS) why ISPs are likely to offer only token bucket policers to 
their users (which would tend to rule out starvation).
"Using Self-interest to Prevent Malice;
Fixing the Denial of Service Flaw of the Internet"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#refb_dplinc>
It is an early workshop-style paper that outlines what we expect a more 
rigorous model would look like (ie it doesn't yet meet your requirement for 
more rigor). And I'm the first to admit, no-one can really predict how such 
subtle distinctions will play out.

All I can say is that each society will be able to control the outcome if 
it chooses to: ruling out starvation is possible with the technology I have 
proposed - but I don't believe such policy choices should be embedded in 
the technology that the IETF gives to the world. No matter how strongly 
some of us believe that starvation is wrong.


>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

Of course. For many years now I've been working as hard as I can, but 
there's a limit to how much we can do - only a few of us have been rowing 
this boat. I hope I have brought it sufficiently to everyone's attention 
that a larger part of the research community will focus on the better 
analysis you'd like.

However, I believe TCP's lack of attention to flow durations alone is 
sufficient grounds for the IETF to be greatly concerned about the current 
resource control approach. We all already know the long-tailed distribution 
of flow durations, so we can all imagine just how bad resource allocations 
are going to be that don't take duration into account.


Bob


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