Re: [re-ECN] preliminary draft of problem statement- authors wanted

João Taveira Araújo <j.araujo@ee.ucl.ac.uk> Tue, 22 September 2009 09:24 UTC

Return-Path: <j.araujo@ee.ucl.ac.uk>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32013A6857 for <re-ecn@core3.amsl.com>; Tue, 22 Sep 2009 02:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.167
X-Spam-Level:
X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 RbvpaKw-2gxg for <re-ecn@core3.amsl.com>; Tue, 22 Sep 2009 02:24:40 -0700 (PDT)
Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by core3.amsl.com (Postfix) with ESMTP id B31433A67A8 for <re-ecn@ietf.org>; Tue, 22 Sep 2009 02:24:39 -0700 (PDT)
Received: from [192.168.1.65] (host86-176-177-5.range86-176.btcentralplus.com [86.176.177.5]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id n8M9LxIE028628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <re-ecn@ietf.org>; Tue, 22 Sep 2009 10:22:08 +0100 (BST)
Message-ID: <4AB89804.8050309@ee.ucl.ac.uk>
Date: Tue, 22 Sep 2009 10:25:24 +0100
From: =?ISO-8859-1?Q?Jo=E3o_Taveira_Ara=FAjo?= <j.araujo@ee.ucl.ac.uk>
Organization: UCL
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: re-ecn@ietf.org
References: <AEDCAF87EEC94F49BA92EBDD49854CC70D1D1EE6@E03MVZ1-UKDY.domain1.systemhost.net> <8A82D1BFEDDE7E4597978355239BBBCB2A238B@PACDCEXCMB06.cable.comcast.com> <AEDCAF87EEC94F49BA92EBDD49854CC70D26249F@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70D26249F@E03MVZ1-UKDY.domain1.systemhost.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-UCL_EE-MailScanner-Information: Please contact mailhelp@ee.ucl.ac.uk for more information
X-MailScanner-ID: n8M9LxIE028628
X-UCL_EE-MailScanner: Found to be clean
X-UCL_EE-MailScanner-From: j.araujo@ee.ucl.ac.uk
Subject: Re: [re-ECN] preliminary draft of problem statement- authors wanted
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2009 09:24:41 -0000

Inline,

toby.moncaster@bt.com wrote:
>> I would change "Myoptic Solutions" to "Existing Work". You have
>> identified two existing ISP solutions: "rate limiting" and "volume
>> limiting". I would add "simple best effort traffic and flow-rate
>> fairness" (RFC5290), as well as ECN (RFC3168) with nonces (RFC3540).
>> You can steal content from sections 3.1.2 and 4.7 of the motivation
>> draft, of course.
>>     
>
> I really wanted a title that conveyed a little more than just "existing work". But I agree "myopic" is the wrong word. Will add some of those other bits as well. Perhaps I should group them into categories (things the network does and things end-systems do?).
>   

I'm not so sure about using the term "existing work" to refer to ad-hoc, 
poorly documented solutions in most cases. They are workarounds, not 
work. Might also want to mention voluntary rate-limiting on the 
end-hosts (p2p apps) as a symptom of dodgy capacity sharing.

I was hoping for more text before bashing the document, but I assume 
it'll take a while before getting to a semi-finished state. I've toyed 
around with a few paragraphs for section 4, but I'm not sure how 
lightweight you want the economics to be. I think the main ideas to get 
across are:

a) congestion as an externality
b) congestion as the marginal cost of provisioning network
c) exposing congestion corrects information asymmetry.

I'm also unsure whether taking re-ECN out of the picture implies taking 
re-feedback out as well, or whether its the framework we want to have 
for any potential solution. Feel free to pick & mix any of the text, 
I'll be waiting for a future revision to bash.

Joao.



4.  Towards a better solution

   In the previous section, we have documented how network operators
   attempt to limit the damage any single user can inflict on others by
   imposing restrictions on user behaviour.  While these solutions
   differ in approach, they all attempt to tackle the root cause
   indirectly by inferring congestion.  To move beyond such shoddy
   patchwork, there is a need to explicitly treat congestion as a cost.

4.1.  Congestion as a cost

   Congestion is a negative externality - an individual's usage of the
   network has a negative impact on others.  Unheeded, the ability to
   inflict congestion on others at no personal cost may lead to a
   "tragedy of the commons", where self-interested end users undermine
   the value of the network through selfish behaviour.  Such an extreme
   case was initially averted due to genuine cooperation through the
   voluntary deployment of TCP.  As increased commercial pressure is
   exerted on the Internet however, the assumption that stakeholders
   will continuously cooperate towards a common goal no longer holds.

   A possible solution is to apply shadow pricing to the negative
   externality, effectively forcing individuals to internalise the costs
   they impose on others and therefore holding individuals accountable
   for their actions.  Kelly [] has shown that charging end-points a
   shadow price proportional to the congestion they cause leads to the
   maximization of social welfare.

   Additionally, shadow pricing plays a dual role, both reflecting the
   social costs of increased bandwidth usage and the marginal cost of
   provisioning the network.  As such, adequate resource pricing can be
   used to recover expansion costs while subscription revenue recovers
   non-recurring costs.

   While exerting economic pressure on end-points effectively induces
   sociable behaviour, retrofitting the Internet with means to enforce
   congestion pricing has proved elusive.  The best-effort delivery
   provided by the Internet was built on the assumption that forwarding
   elements should discard traffic they are unable to service.  While
   remarkable in its simplicity, this design choice has lead to an
   Internet which is opaque to failure.  As congestion is viewed end-to-
   end, only end-points hold information on the quality of service
   provided by the network.  In this case the buyer knows more about the
   product being sold than the seller.  While this is converse to
   Akerlof's classic examples of information asymmetry [], the outcome
  is similar, resulting in a suppressed market price which in turn
   leads to reduced investment in supply.

(...)

4.2.  The limitations of ECN in exposing cost

   The lack of accountability for congestion was partially addressed
   with the introduction of ECN [], an explicit marking scheme to
   indicate the onset of congestion.  While ECN was introduced to
   maintain networks operating below the point where losses would be
   experienced, as a side-effect it revealed congestion downstream of
   the congested link, allowing network devices to quantify congestion
   without the need for inspecting transport headers.

   This newfound visibility of congestion was duly exploited by Kelly
   [].  Using ECN, a network could apply shadow pricing by simply
   charging the upstream network proportionally to the amount of
   congestion marked traffic it sent.  Unfortunately, this scheme proved
   impractical and suffers from shortcomings derived from the asymmetry
   inherent to classic feedback.

   The fundamental problem with using ECN for congestion pricing is that
   it reveals the correct metric, but to the wrong entities.
   Intermediate routers can only view congestion ex post and are
   therefore not only unable to act upon the information provided, but
   also incapable of verifying its integrity.

(..)

4.3.  Refeedback for congestion exposure

(...)