Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Michael Menth <menth@informatik.uni-wuerzburg.de> Fri, 02 October 2009 05:32 UTC

Return-Path: <menth@informatik.uni-wuerzburg.de>
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 101643A6982 for <re-ecn@core3.amsl.com>; Thu, 1 Oct 2009 22:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.687
X-Spam-Level:
X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_20=-0.74, HELO_EQ_DE=0.35]
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 nHaclI4USr6A for <re-ecn@core3.amsl.com>; Thu, 1 Oct 2009 22:31:59 -0700 (PDT)
Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 640783A68C3 for <re-ecn@ietf.org>; Thu, 1 Oct 2009 22:31:58 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6AA4F5BA73; Fri, 2 Oct 2009 07:33:22 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 672DC5BA6D; Fri, 2 Oct 2009 07:33:22 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [192.168.1.2] (f051000100.adsl.alicedsl.de [78.51.0.100]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 119BC5CD4B; Fri, 2 Oct 2009 07:33:22 +0200 (CEST)
Message-ID: <4AC59062.1070700@informatik.uni-wuerzburg.de>
Date: Fri, 02 Oct 2009 07:32:18 +0200
From: Michael Menth <menth@informatik.uni-wuerzburg.de>
Organization: University of Wuerzburg
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
References: <200910020007.n9207Yd9028543@bagheera.jungle.bt.co.uk>
In-Reply-To: <200910020007.n9207Yd9028543@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, uqar@huawei.com, re-ECN unIETF list <re-ecn@ietf.org>
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: menth@informatik.uni-wuerzburg.de
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: Fri, 02 Oct 2009 05:32:02 -0000

Hi Bob,

Bob Briscoe schrieb:
> An example may help. Two options my own company offers to residential 
> customers for the same access rate today are:
> volume allowance         charge
> 10GB/month               GBP15/month
> 20GB/month               GBP20/month
> This is like saying basic access with zero usage is GBP10 then add 
> GBP5/10GB/month for usage. Even if this ISP only offered one tariff 
> (say GBP18/month) it still notionally includes GBP8 to put towards 
> capacity expansion - it's just a single average price where light 
> users contribute more to new capacity than is "proper" and heavy users 
> less.
>
> I would propose that a congestion allowance would replace this volume 
> allowance, so it might look like this:
> congestion-volume
> allowance                charge
> 10MB/month               GBP15/month
> 20MB/month               GBP20/month
> This assumes congestion is expected to be about 0.1% on average so 
> 1/1000 of average volume is congestion-volume. But with a 
> congestion-volume allowance you could transfer a lot more volume if 
> you did it at night or even at peak time if you used a protocol like 
> LEDBAT.
>

Is a congestion allowance in MB/month which is controlled by a simple 
counter at the access really helpful? This allows users to cause lots of 
congestion at the beginning of the month. I thought that a maximum 
congestion rate in KB/s which is controlled by a kind of token bucket is 
needed to do congestion policing and that this is one of the core 
concepts of re-refeedback to achieve fair bandwidth sharing among users? 
This corresponds rather to a maximum access speed  than to a maximum 
amount of volume allowance. A monthly volume allowance can be combined 
with both a maximum access speed and a maximum congestion rate.

True or not? Where's the fault?

Apart from that, I wonder whether a monthly congestion allowance or a 
maximum congestion rate can be sold to the customer because that is more 
abstract and harder to verify for the user. Even I do not know what I 
get for a congestion allowance of 1 MB/month or a maximum congestion 
rate of 10 KB/s. That was one of the criticisms I've heard when 
discussing about re-feedback. Opinions?

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:menth@informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn