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

[Bob Briscoe <[e-mail]>]

Michael,

At 13:12 02/10/2009, Michael Menth wrote:
>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 believe it's important to enable *a* viable business model, as long 
as everyone understands our purpose is to allow diversity of business 
models. I don't believe we should talk about business models in the 
BoF though. We should be able to do a whole BoF just talking about 
ways of managing congestion and traffic, without mentioning money.

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

I was sloppy when I said monthly allowance. I meant this would be fed 
out to the user over the month - more like a congestion rate. But 
actually the canonical model we've worked on is a congestion rate fed 
into a large token bucket that can be drawn on when traffic causes 
congestion. See:
Policing Freedom to Use the Internet Resource Pool
<http://www.bobbriscoe.net/projects/refb/#polfree>

We're working on a variant that prevents someone injecting a burst of 
congestion into the network if they have built up a large congestion 
allowance over a period of inactivity or low congestion.

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

Actually, congestion constraints need not *add* to existing 
contracts. They can *replace* peak and committed bit-rate on shared 
media (wireless, cable, PON). I believe each user could be allowed to 
use the total physical bit-rate of the shared medium with only a 
constraint on congestion instead. This is a bit of an arm-waving 
claim at the moment, but I'd be interested if anyone can verify it.

>As this quality measure does not depend on well controllable 
>settings, it is hard to validate but still useful.

I think you mean it doesn't use well-known parameters (rather than 
well-controllable). It's intended to be both controllable and 
verifiable. And it is the minimum necessary thing to control. 
Operators that limit bit-rate or volume are actually trying to limit 
congestion, and they end up having to over-constrain because they 
aren't controlling the metric they really want to control.

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

Yes.

An important aside: you can use congestion policers for edge-policing 
a Diffserv class, not just BE. This wouldn't make sense for a class 
consisting only of inelastic traffic, but it would if some elastic 
was pooled with the inelastic. Then the link provisioning can be much 
less generous (=> lower cost to the user) - it would only have to 
provision for the mean traffic matrix, without worrying unduly about 
the variance, because variation from the mean matrix would be 
absorbed by the congestion responses of the end-systems without 
unduly affecting the overall service.

Further, today's Diffserv edge policing by bit-rate is only 
appropriate for aggregated sites (e.g. medium to large business 
customers). Congestion policing would make Diffserv applicable to 
individual sources, not just aggregated sites.



Bob


>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: [phone] (new), fax: [phone]
>mailto:[e-mail]
>http://www3.informatik.uni-wuerzburg.de/research/ngn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design