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