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

Michael Menth <menth@informatik.uni-wuerzburg.de> Fri, 02 October 2009 12:11 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 711CC28C0E3 for <re-ecn@core3.amsl.com>; Fri, 2 Oct 2009 05:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, 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 6QaXjlc4nVnQ for <re-ecn@core3.amsl.com>; Fri, 2 Oct 2009 05:11:36 -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 D242E3A67E6 for <re-ecn@ietf.org>; Fri, 2 Oct 2009 05:11:35 -0700 (PDT)
Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id BDF845BA3D; Fri, 2 Oct 2009 14:13:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id BB7A15BA26; Fri, 2 Oct 2009 14:13:00 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de
Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 9A01E5CD47; Fri, 2 Oct 2009 14:13:00 +0200 (CEST)
Message-ID: <4AC5EE27.9090303@informatik.uni-wuerzburg.de>
Date: Fri, 02 Oct 2009 14:12:23 +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> <4AC59062.1070700@informatik.uni-wuerzburg.de>
In-Reply-To: <4AC59062.1070700@informatik.uni-wuerzburg.de>
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 12:11:37 -0000

Hi all,

sorry, the many responses to my email telling that it's not our business 
to talk about what to sell to customers tells me that I asked my 
question in the wrong way. I need to rephrase it: can a simple 
congestion byte counter at the access achieve fair bandwidth sharing per 
user or does the congestion rate need to be limited? Congestion volume 
policing or congestion rate policing? I am more interested in the 
control model, not so much in exact user contracts. Nevertheless, I 
think that we should be able to explain the potential impact of 
re-feedback on user contracts.

When taking advantage of re-feedback, my understanding is that 
congestion policing is a core principle - correct me if I am wrong! The 
parameters of the policers have an impact on how well a user can use the 
Internet in times of congestion. So, users should choose gold, silver, 
bronce according to their willingness to tolerate slower connections in 
times of congestion. That is probably the additional dimension, 
re-feedback can add to conventional contracts. As this quality measure 
does not depend on well controllable settings, it is hard to validate 
but still useful. Essentially, the parameters for congestion policers at 
the access can differentiate the sustainability of the Internet access 
in times of congestion. From a user perspective it is similar to 
DiffServ: best effort can provide a great service in an underutilized 
network, the difference to AF/EF is visible only in times of congestion.

Is that correct?

Regards,

    Michael

Michael Menth schrieb:
> 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