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
- [re-ECN] ECN fundamentals pt2/2 (was: Re: Name fo… Bob Briscoe
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… Michael Menth
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… Mirja Kuehlewind
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… philip.eardley
- Re: [re-ECN] ECN fundamentals pt2/2 Matthew Ford
- Re: [re-ECN] ECN fundamentals pt2/2 Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… Michael Menth
- Re: [re-ECN] ECN fundamentals pt2/2 STUART VENTERS
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… Joe Babiarz
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… Bob Briscoe
- Re: [re-ECN] ECN fundamentals pt2/2 Bob Briscoe
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… philip.eardley
- Re: [re-ECN] ECN fundamentals pt2/2 Bob Briscoe
- Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Nam… Bob Briscoe