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

From: Bob Briscoe <[email-masked]>
Date: Fri, 02 Oct 2009 01:05:15 +0100

Tina,

Here's the rest of my answers/responses.

I said before and I'll say again, you are asking 
v important fundamental questions, which I'm glad to try to answer...

Also, I repeat we need to write an FAQ. Does 
anyone on the list want to help with that?

At 09:17 08/09/2009, Tina TSOU wrote:
[snip first half of questions responded to 8/9/09]

>C, Each sender/receiver, apply/lease bandwidth 
>before using the network. When the congestion 
>occurs in the network, is it proper to recharge them?

The monthly fees one pays for Internet cover two main types of cost:
- operational (electric bills, fixing faults) and 
overheads (sales, marketing, legal etc)
- investment in future capacity expansion.

I'm not keen on congestion charges - I prefer 
congestion limits - but to answer your question, 
a congestion charge isn't an extra charge, it's a 
part of what you already pay. And it funds future 
upgrades, not past. It says "I'm willing to pay 
for you to upgrade those links that have 
generated most ECN-marked bytes, so that they won't in future."

[Importantly, at the IETF there's no need to talk 
about charging at all. We only need to expoase a 
congestion metric. It's not up to the IETF to 
decide whether the metric should be used for 
charging, policing or generally holding people 
accountable. However, one of my primary 
motivations for exposing congestion is that 
economics says the *best* accountability metric 
for a shared resource is congestion. So I've 
taken "is it proper" to mean "under a pricing 
plan that an economist would recommend to 
maximise social welfare, is it proper".]

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.

It solves the problem of how much each individual 
should contribute to expansion of the shared 
parts of the network, and by how much each shared 
part of the network needs to be expanded.

Actually this is a simplification. There's a 
video of my recent tutorial at the Trilogy summer 
school on "practical microeconomics and Internet 
resource sharing protocols" here:
<http://inl.info.ucl.ac.be/tutorials/tfiss09-briscoe>
When I get to slides 22 & 23 at the very end of Pt1, I explain this properly.

>In addition, who will be charged? The sender? The receiver?

Again, this isn't up to me or the IETF - it's up 
to each ISP. I believe we should provide metrics 
so that either sender (re-ECN) or receiver (ECN) 
can be made accountable for congestion.

Having said that, I have strong concerns about 
making the receiver accountable for congestion or 
for anything related to usage at the network 
layer (whether volume or congestion-volume), 
because receivers ultimately can't control what 
is sent to them (due to DDoS). I.e. in the above 
example, I would recommend counting only sent 
congestion (re-ECN) against the allowance, not received (ECN).

>D, In addition, the new technique deployment 
>problem, need all the devices to support it.

Not at all. Like ECN, re-ECN is designed to be 
permanently partially deployed by some networks, 
some senders and some receivers.

* Network: each network that wants to have 
congestion exposed can deploy ECN independently 
of other networks and deploy policing at its trust boundaries.
   - Not all forwarding equipment can do ECN 
today - fine if it drops instead, esp if it's not frequently congested

* Sender: there's a distinction between re-ECN & 
non-re-ECN packets - a sender can choose which it sends.
   - a network that is policing based on re-ECN 
info is also likely to rate-limit non-re-ECN 
packets; loosely at first to encourage hosts to 
upgrade, then more strictly once there's no 
excuse for hosts not to have upgraded.

* Receiver: a re-ECN sender works OK with an ECN 
receiver now. If you upgrade the receiver it works more precisely though.

>It is a bit difficult to deploy.

I'm not saying it will be easy (there will 
probably be firewalls that block it etc), I'm 
just saying it's definitely been designed to be 
incrementally deployable. And a lot of thought 
has gone into the independent incentives of each 
stakeholder in order to deploy their piece of the picture.

>Another problem is charging. If the access node 
>should do the congestion charging, it makes the 
>network devices heavy. Is it proper for the cost consideration?

I wouldn't recommend congestion charging - no-one 
likes it. We designed re-ECN so we could do 
congestion policing instead. Nonetheless, even if 
an ISP were congestion charging, it would be as 
easy as charging for volume measured over a month 
- but instead you measure only the volumes of 
marked bytes and ignore those not marked. That's 
just a dead simple pair of counters like you do for RADIUS today.

The whole idea is to allow all the network 
devices to be simpler. Rather than having all the 
resource scheduling and policing on every 
forwarding device, they just do bulk ECN marking 
and re-ECN gets this information to one device 
(policer) at the ingress so it can see all the 
congestion the user is causing in the whole 
Internet. Policing can then be done at that one 
device for the whole Internet at once. And the 
hosts have the incentive to do all the scheduling 
correctly, rather than doing scheduling in all 
the queues. You get a full QoS system with nothing but ECN in the queues.

For instance, one aim is to be able to have 
all-optical interconnect between domains. I 
imagine it would be feasible to do ECN in 
photonics, but I suspect a hierarchical scheduler 
and policers would be much much harder.

Another aim of re-ECN was to ensure ingress 
policer could be simple - the simplest sufficient 
policer for re-ECN is much like a bulk token 
bucket. However, my main concern on complexity is 
the device I call a dropper that re-ECN needs at 
the egress (intended to ensure the sender has no 
incentive to lie about re-ECN). That also does 
minimal processing per packet, BUT it requires per-flow state.

My PhD thesis has all the pseudocode for each of 
the devices, and summary tables of instructions 
per packet and memory usage etc. I can send if 
you're interested, <http://www.bobbriscoe.net/pubs.html#refb-dis>
altho I'd rather finish the report version I'm 
preparing which will be much shorter (perhaps 80pp instead of 256pp).

>
>a, The network is open. It is difficult to let 
>the network device to be a police, to control 
>all kinds of service of the user strictly. The 
>more illumination, the more temptation. The 
>improvement of the user experience would be more 
>proper to be placed in the application level.

This has been the whole point of my last 10yrs of 
research: to find the minimal policing necessary 
to ensure as much freedom and openness as 
possible, but only restricting those who 
excessively restrict the freedom of others (which 
excessive congestion represents). Thus giving the 
right incentives to the app and transport layer 
to improve everyone else's user experience.

This 6pp workshop paper is a good summary of the policing approach:
Policing Freedom to Use the Internet Resource Pool
<http://www.bobbriscoe.net/projects/refb/#polfree>

>b. It should not be very often that the network 
>congestion occurs. If so, that means that the 
>network needs to expanse its capacity. Even the 
>congestion in the flash cloud (peak time) should 
>not be very serious; otherwise the network needs to expands its capacity.

I disagree. If there's not congestion somewhere 
along a path, it means the transport protocols 
are broken. Each elastic flow should be able to 
go fast enough to cause the onset of congestion. 
If not, it will only complete later than it could have done.

The trick is to ensure congestion != impairment.
ECN breaks the link between the two - you get 
congestion signals but minimal congestion delay 
or jitter and very nearly zero loss.

The rule of thumb about keeping utilisation low 
comes from focusing on core networks, not on the 
whole path. I'm talking about the whole 
internetwork. But once we can break the link 
between congestion and impairment, core networks 
won't need to be congestion-free either. Not 
necessarily persistently congested - periods of 
ECN congestion signals then silence.

Another argument: it should be possible to have 
any empty capacity always filled by scavenger 
data. Then a low background level of congestion 
signalling means the network is always being 
fully used, but as soon as any non-scavenger data 
comes along, the scavenger transports should 
yield, nearly as if the network had been empty.

>c, use the existing technique, take good use of 
>flow classification in the egress of each SP, 
>the egress of each special telephone line user; 
>for the up streaming traffic for individual 
>user, except to give the packets for dedicated 
>device (e.g. IP telephony) corresponding priority, put the rest in BE queue.
>d, through some simple technique, to assure the 
>all or most of the users’ experience of inelastic flow (audio, video).

Above I've been talking about the wider problem 
of fair management of *all* traffic. Yes, we have 
worked out ways to get VoIP working without 
solving the wider problem - either without 
in-network QoS mechanisms because VoIP's not very 
demanding anyway, or with in-network QoS for 
carrier-grade assurances as you mention. But the 
latter with in-network QoS has still proved too 
complex to get much inter-domain deployment, 
except for demonstrators. Given we had VoIP 
working over ARPAnet, that's pretty pathetic.

By approaching the problem of fair management of 
*all* traffic (with re-ECN), it turns out that 
you get inter-domain QoS as a neat (and rather 
valuable) side-effect. In theory, ECN keeps all 
the queue short with v low queuing delay & jitter 
and hardly any loss - for all traffic. Then 
re-ECN does the sharing out of capacity, which 
deals with the bandwidth allocation dimension. 
And the congestion exposed in packets gives all 
the right metrics inter-domain accounting, by 
just locally counting marked bytes crossing the 
border. And the API is "just go faster if you 
want" - there's no prior permission required, 
whether setting up a Diffserv SLA or flow signalling or anything.

>Just my two cents.

and my twenty.

Cheers

Bob

>
>
>B. R.
>Tina
><http://tinatsou.weebly.com/contact.html>http://tinatsou.weebly.com/contact.html
>
>
>
>
>----- Original Message -----
>From: <mailto:[email-masked]>Bob Briscoe
>To: <mailto:[email-masked]>re-ECN unIETF list
>Cc: <mailto:[email-masked]>Ingemar Johansson S
>Sent: Tuesday, September 08, 2009 4:03 PM
>Subject: Re: [re-ECN] Name for BoF?
>Folks,
>More views welcome?
>Summary of 'votes' so far...
>At 00:08 08/09/2009, João Taveira Araújo wrote:
> >Bob Briscoe wrote:
> >>Folks,
> >>
> >>One important issue I never raised - the name.
> >>
> >>Congestion Exposure
> >>Congestion Visibility
> >>Congestion Transparency
>Congestion Exposure seems to get everyone's approval
>
> >>And a short form:
> >>CEX?
> >>re-ECN?
>Everyone agrees on what it shouldn't be: Not re-ECN
>Less agreement on a replacement:
>          CEX
>          ConEx
>          re-con
>Also, one vote for "Wait until later."
>
>I'm not so keen on including "Con" for obvious
>reasons :) Choosing something like that can come back and bite you.
>It also sounds somehow as much like config as congestion.
>Some time ago, Toby came up with a clever one:
>          C-IT (pron. "See it") for Congestion Information Transparency.
>not so useful if we're not calling it transparency tho.
>Hey, I've just had a thought, the flag (or
>codepoint) for rest-of-path congestion could be
>called CEX (Congestion Expected), rather
>ambiguous with ECN's "Congestion Experienced (CE)" tho.
>
>Bob
>
>
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research
>_______________________________________________
>re-ECN mailing list
><mailto:[email-masked]>[email-masked]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: Michael Menth <[email-masked]>
Date: Fri, 02 Oct 2009 07:32:18 +0200

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 

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:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 2 Oct 2009 10:28:21 +0200

Hi Michael,

> discussing about re-feedback. Opinions?
I don't see that you have to sell the congestion rate to the costumer. It's 
just one part of the contract which will have some more or less meaningful 
names like "fast access" or "high speed access". People don't know what the 
max. access speed in todays contracts means neither...

Mirja

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

web: www.ikr.uni-stuttgart.de
email: [email-masked]
tel: +49(0)711/685-67973
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 2 Oct 2009 10:08:28 +0100

I agree.

In practice I guess that the consumer will have a choice between (say) 3 tiers of service (basic, plus, super advanced). although different monthly congestion allowances (& maybe difference maximum congestion rates) will be part of that, most consumers won't really understand it (just as today most don't understand what 20mb/s or 1gb mean). But there are independent experts that check comparative performance of different ISPs, and you can run a program to check what performance you actually get.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mirja Kuehlewind
Sent: 02 October 2009 09:28
To: [email-masked]; [email-masked]
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Hi Michael,

Mirja

[email-masked]

---

From: Matthew Ford <[email-masked]>
Date: Fri, 02 Oct 2009 10:12:31 +0100

> max. access speed in todays contracts means neither...

+1. Furthermore, I think we should probably call 'rathole' whenever the 
question of how congestion volume gets translated into commercial 
contracts or marketing is raised.

Mat

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 2 Oct 2009 12:22:06 +0300

When we started the NSIS work on QoS someone was asking me about how the
charging for these things will work out. I responded by saying that
"someone will figure that out later". Very similar to how Mirja and Mat
responded in this discussion. 

The problem with many of these QoS things is that they make a lot of
sense for researchers (but unfortunately not for anyone else). 

Hence, I believe it is important to understand some of these incentive
models since otherwise you end up having another nice technology (again)
that people cannot make us of. Behind all these new protocol mechanisms
are business models hidden that better make some sense. 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Matthew Ford
>Sent: 02 October, 2009 12:13
>To: Mirja Kuehlewind
>Cc: [email-masked]
>Subject: Re: [re-ECN] ECN fundamentals pt2/2
>
>>> 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?
>>>
>> I don't see that you have to sell the congestion rate to the 
>costumer. 
>> It's just one part of the contract which will have some more or less 
>> meaningful names like "fast access" or "high speed access". People 
>> don't know what the max. access speed in todays contracts 
>means neither...
>
>question of how congestion volume gets translated into 
>commercial contracts or marketing is raised.
>
>Mat

---

From: Michael Menth <[email-masked]>
Date: Fri, 02 Oct 2009 14:12:23 +0200

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:
>> users contribute more to new capacity than is "proper" and heavy 
>> users less.
>>
> 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.
>
> congestion rate of 10 KB/s. That was one of the criticisms I've heard

---

From: "STUART VENTERS" <[email-masked]>
Date: Fri, 2 Oct 2009 09:20:25 -0500

Bob,

With regards to incentives and economics,
 
I can see that re-ECN tends to encourage customers to make optimal use of the network.
   (Nudges them to carefully travel along the edge of a congestion cliff, which is actually optimal.
      I.E. low latency, low drop rate, and full use of resources.  Pretty cool.)
 
I'm less clear understanding the service provider incentives.
  If you are paid for congestion, is there a short term incentive to cause or eliminate it?

Regards,
 
Stuart

ps. Optimizing is all about finding the right cost function.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Bob Briscoe
Sent: Thursday, October 01, 2009 7:05 PM
To: Tina TSOU
Cc: Ingemar Johansson S; [email-masked]; re-ECN unIETF list
Subject: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Tina,

I said before and I'll say again, you are asking v important fundamental questions, which I'm glad to try to answer...

Also, I repeat we need to write an FAQ. Does anyone on the list want to help with that?

C, Each sender/receiver, apply/lease bandwidth before using the network. When the congestion occurs in the network, is it proper to recharge them? 

The monthly fees one pays for Internet cover two main types of cost: 
- operational (electric bills, fixing faults) and overheads (sales, marketing, legal etc)
- investment in future capacity expansion.

I'm not keen on congestion charges - I prefer congestion limits - but to answer your question, a congestion charge isn't an extra charge, it's a part of what you already pay. And it funds future upgrades, not past. It says "I'm willing to pay for you to upgrade those links that have generated most ECN-marked bytes, so that they won't in future."

[Importantly, at the IETF there's no need to talk about charging at all. We only need to expoase a congestion metric. It's not up to the IETF to decide whether the metric should be used for charging, policing or generally holding people accountable. However, one of my primary motivations for exposing congestion is that economics says the *best* accountability metric for a shared resource is congestion. So I've taken "is it proper" to mean "under a pricing plan that an economist would recommend to maximise social welfare, is it proper".]

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.

It solves the problem of how much each individual should contribute to expansion of the shared parts of the network, and by how much each shared part of the network needs to be expanded.

Actually this is a simplification. There's a video of my recent tutorial at the Trilogy summer school on "practical microeconomics and Internet resource sharing protocols" here:
<  <http://inl.info.ucl.ac.be/tutorials/tfiss09-briscoe> http://inl.info.ucl.ac.be/tutorials/tfiss09-briscoe>
When I get to slides 22 & 23 at the very end of Pt1, I explain this properly.

Again, this isn't up to me or the IETF - it's up to each ISP. I believe we should provide metrics so that either sender (re-ECN) or receiver (ECN) can be made accountable for congestion.

Having said that, I have strong concerns about making the receiver accountable for congestion or for anything related to usage at the network layer (whether volume or congestion-volume), because receivers ultimately can't control what is sent to them (due to DDoS). I.e. in the above example, I would recommend counting only sent congestion (re-ECN) against the allowance, not received (ECN).

D, In addition, the new technique deployment problem, need all the devices to support it. 

Not at all. Like ECN, re-ECN is designed to be permanently partially deployed by some networks, some senders and some receivers.

* Network: each network that wants to have congestion exposed can deploy ECN independently of other networks and deploy policing at its trust boundaries.
  - Not all forwarding equipment can do ECN today - fine if it drops instead, esp if it's not frequently congested

* Sender: there's a distinction between re-ECN & non-re-ECN packets - a sender can choose which it sends.
  - a network that is policing based on re-ECN info is also likely to rate-limit non-re-ECN packets; loosely at first to encourage hosts to upgrade, then more strictly once there's no excuse for hosts not to have upgraded.

* Receiver: a re-ECN sender works OK with an ECN receiver now. If you upgrade the receiver it works more precisely though.

I'm not saying it will be easy (there will probably be firewalls that block it etc), I'm just saying it's definitely been designed to be incrementally deployable. And a lot of thought has gone into the independent incentives of each stakeholder in order to deploy their piece of the picture.

Another problem is charging. If the access node should do the congestion charging, it makes the network devices heavy. Is it proper for the cost consideration?

I wouldn't recommend congestion charging - no-one likes it. We designed re-ECN so we could do congestion policing instead. Nonetheless, even if an ISP were congestion charging, it would be as easy as charging for volume measured over a month - but instead you measure only the volumes of marked bytes and ignore those not marked. That's just a dead simple pair of counters like you do for RADIUS today.

The whole idea is to allow all the network devices to be simpler. Rather than having all the resource scheduling and policing on every forwarding device, they just do bulk ECN marking and re-ECN gets this information to one device (policer) at the ingress so it can see all the congestion the user is causing in the whole Internet. Policing can then be done at that one device for the whole Internet at once. And the hosts have the incentive to do all the scheduling correctly, rather than doing scheduling in all the queues. You get a full QoS system with nothing but ECN in the queues.

For instance, one aim is to be able to have all-optical interconnect between domains. I imagine it would be feasible to do ECN in photonics, but I suspect a hierarchical scheduler and policers would be much much harder. 

Another aim of re-ECN was to ensure ingress policer could be simple - the simplest sufficient policer for re-ECN is much like a bulk token bucket. However, my main concern on complexity is the device I call a dropper that re-ECN needs at the egress (intended to ensure the sender has no incentive to lie about re-ECN). That also does minimal processing per packet, BUT it requires per-flow state.

My PhD thesis has all the pseudocode for each of the devices, and summary tables of instructions per packet and memory usage etc. I can send if you're interested, <  <http://www.bobbriscoe.net/pubs.html#refb-dis> http://www.bobbriscoe.net/pubs.html#refb-dis>
altho I'd rather finish the report version I'm preparing which will be much shorter (perhaps 80pp instead of 256pp).

a, The network is open. It is difficult to let the network device to be a police, to control all kinds of service of the user strictly. The more illumination, the more temptation. The improvement of the user experience would be more proper to be placed in the application level.

This has been the whole point of my last 10yrs of research: to find the minimal policing necessary to ensure as much freedom and openness as possible, but only restricting those who excessively restrict the freedom of others (which excessive congestion represents). Thus giving the right incentives to the app and transport layer to improve everyone else's user experience. 

This 6pp workshop paper is a good summary of the policing approach:
Policing Freedom to Use the Internet Resource Pool
<  <http://www.bobbriscoe.net/projects/refb/#polfree> http://www.bobbriscoe.net/projects/refb/#polfree>

b. It should not be very often that the network congestion occurs. If so, that means that the network needs to expanse its capacity. Even the congestion in the flash cloud (peak time) should not be very serious; otherwise the network needs to expands its capacity.

I disagree. If there's not congestion somewhere along a path, it means the transport protocols are broken. Each elastic flow should be able to go fast enough to cause the onset of congestion. If not, it will only complete later than it could have done.

The trick is to ensure congestion != impairment. 
ECN breaks the link between the two - you get congestion signals but minimal congestion delay or jitter and very nearly zero loss.

The rule of thumb about keeping utilisation low comes from focusing on core networks, not on the whole path. I'm talking about the whole internetwork. But once we can break the link between congestion and impairment, core networks won't need to be congestion-free either. Not necessarily persistently congested - periods of ECN congestion signals then silence. 

Another argument: it should be possible to have any empty capacity always filled by scavenger data. Then a low background level of congestion signalling means the network is always being fully used, but as soon as any non-scavenger data comes along, the scavenger transports should yield, nearly as if the network had been empty.

c, use the existing technique, take good use of flow classification in the egress of each SP, the egress of each special telephone line user; for the up streaming traffic for individual user, except to give the packets for dedicated device (e.g. IP telephony) corresponding priority, put the rest in BE queue.
d, through some simple technique, to assure the all or most of the users' experience of inelastic flow (audio, video).

Above I've been talking about the wider problem of fair management of *all* traffic. Yes, we have worked out ways to get VoIP working without solving the wider problem - either without in-network QoS mechanisms because VoIP's not very demanding anyway, or with in-network QoS for carrier-grade assurances as you mention. But the latter with in-network QoS has still proved too complex to get much inter-domain deployment, except for demonstrators. Given we had VoIP working over ARPAnet, that's pretty pathetic.

By approaching the problem of fair management of *all* traffic (with re-ECN), it turns out that you get inter-domain QoS as a neat (and rather valuable) side-effect. In theory, ECN keeps all the queue short with v low queuing delay & jitter and hardly any loss - for all traffic. Then re-ECN does the sharing out of capacity, which deals with the bandwidth allocation dimension. And the congestion exposed in packets gives all the right metrics inter-domain accounting, by just locally counting marked bytes crossing the border. And the API is "just go faster if you want" - there's no prior permission required, whether setting up a Diffserv SLA or flow signalling or anything.

Just my two cents.

and my twenty.

Cheers

Bob

B. R.
Tina
http://tinatsou.weebly.com/contact.html

----- Original Message ----- 

From: Bob Briscoe <mailto:[email-masked]>  

To: re-ECN unIETF list <mailto:[email-masked]>  

Cc: Ingemar  <mailto:[email-masked]> Johansson S 

Folks,

More views welcome?

         CEX 

         ConEx 

         re-con 

Bob

re-ECN mailing list 

[email-masked]

---

From: "Joe Babiarz" <[email-masked]>
Date: Fri, 2 Oct 2009 11:02:44 -0400

Would like to add that the protocol should be designed so that it does not
discourage ISPs from increasing capacity of their networks. We do not want
ISPs be making more money because their network is congested.

Regards, Joe.
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, October 02, 2009 5:08 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

I agree.

In practice I guess that the consumer will have a choice between (say) 3
tiers of service (basic, plus, super advanced). although different monthly
congestion allowances (& maybe difference maximum congestion rates) will be
part of that, most consumers won't really understand it (just as today most
don't understand what 20mb/s or 1gb mean). But there are independent experts
that check comparative performance of different ISPs, and you can run a
program to check what performance you actually get.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mirja Kuehlewind
Sent: 02 October 2009 09:28
To: [email-masked]; [email-masked]
Subject: Re: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Hi Michael,

Mirja

web: www.ikr.uni-stuttgart.de
email: [email-masked]
tel: +49(0)711/685-67973
-------------------------------------------------------------------
_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn
_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn
No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.409 / Virus Database: 270.14.3/2409 - Release Date: 10/02/09
06:46:00

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 02 Oct 2009 17:53:06 +0100

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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 02 Oct 2009 18:01:50 +0100

Hannes,

The answer here is that you're right it's important to understand 
some of these incentive models, but the IETF isn't really an 
approrpriate forum, as that's not where the expertise is.

On that subject, on Wed we had a big event in London with three 
expert panels (commercial, public policy & technical) where the 
purpose was to assess the re-ECN proposal on all three fronts. Senior 
execs (CEOs, CTOs) as well as experts in these three fields flew in 
from around the world with a few on video links too. The organisers 
(GIIC) will be producing a report and we hope to give a report into 
the BoF if the organisers are happy to.

Bob

---

From: <[email-masked]>
Date: Fri, 2 Oct 2009 18:05:53 +0100

Agree with you joe. 

One of the barriers to investment is that increasing capacity may not lead to better e2e qos (because the problem is somewhere else). By exposing information about congestion, it should be easier to assign blame correctly about where the bottleneck is - and therefore improve the incentive to invest in more capacity (I can tell you're a good guy, so shift my traffic to you - you gain by getting the connection etc charge). 

Maybe that sounds a rather indirect argument - but given there are incentives to invest in capacity today, I think better information about the bottlenecks should help the incentives to invest. 

The obvious counter-example is where a consumer has only one choice of local provider and then indeed it does seem that the ISP can make "more money because their network is congested". But the problem here is that the ISP has a termination monopoly, which basically needs to be tackled by regulation in some shape or form - there is exactly the same issue today. 

-----Original Message-----
From: Joe Babiarz [mailto:[email-masked]] 
Sent: 02 October 2009 16:03
To: Eardley,PL,Philip,DEE1 R; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)

Regards, Joe.
[email-masked]

-----Original Message-----

I agree.

-----Original Message-----

Hi Michael,

Mirja

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 02 Oct 2009 18:36:24 +0100

Stuart,

Another excellent question - and candidate for our FAQ.
Inline...

At 15:20 02/10/2009, STUART VENTERS wrote:

Bob,

With regards to
incentives and economics,

I can see that
re-ECN tends to encourage customers to make optimal use of the
network.

(Nudges them to carefully travel along the edge of a
congestion cliff, which is actually optimal.

I.E. low latency, low drop rate, and full
use of resources.  Pretty cool.)

I'm less clear
understanding the service provider incentives.

If you are paid for congestion, is there a short term incentive to
cause or eliminate it?

You're right that in the long term, there's an incentive to run along a
congestion cliff, neither causing nor eliminating.

In the short term, if the ISP introduces fake congestion signals, or
persistently underprovisions, it puts itself in the same position as
doing these things would today - it risks losing customers to other
ISPs.

If it enjoys a monopoly, then it could play these games. But it can with
or without re-ECN - it can already overcharge or give crap quality
without re-ECN.

One case to be careful of is where congestion policing is applied to the
sender, but the the receiver's access network introduces congestion. Then
no-one can get to the receiver without going through the terminating
access network, but the receiver seems not to pay the cost of having
chosen this naughty access network.

The sender will reduce its rate when congestion is high, so the receiver
will suffer crap speed from its choice and tend to switch to another
network. But I think overall this would be a good scam for the
terminating network in terms of getting more money for poorer quality.
The way round this is to ensure the receiver sometimes contributes -
there are a number of ways of doing that, which can be built on the
current protocol.

HTH

Bob

Regards,

Stuart

ps. Optimizing is
all about finding the right cost function.

-----Original Message-----

From: [email-masked]
[
mailto:[email-masked]]On Behalf Of Bob Briscoe

To: Tina TSOU

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

Tina,

I said before and I'll say again, you are asking v important
fundamental questions, which I'm glad to try to answer...

Also, I repeat we need to write an FAQ. Does anyone on the list want
to help with that?

C, Each sender/receiver,
apply/lease bandwidth before using the network. When the congestion
occurs in the network, is it proper to recharge them?

- operational (electric bills, fixing faults) and overheads (sales,
marketing, legal etc)

I'm not keen on congestion charges - I prefer congestion limits - but
to answer your question, a congestion charge isn't an extra charge, it's
a part of what you already pay. And it funds future upgrades, not past.
It says "I'm willing to pay for you to upgrade those links that have
generated most ECN-marked bytes, so that they won't in
future."

[Importantly, at the IETF there's no need to talk about charging at
all. We only need to expoase a congestion metric. It's not up to the IETF
to decide whether the metric should be used for charging, policing or
generally holding people accountable. However, one of my primary
motivations for exposing congestion is that economics says the *best*
accountability metric for a shared resource is congestion. So I've taken
"is it proper" to mean "under a pricing plan that an
economist would recommend to maximise social welfare, is it
proper".]

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.

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.

It solves the problem of how much each individual should contribute
to expansion of the shared parts of the network, and by how much each
shared part of the network needs to be expanded.

Actually this is a simplification. There's a video of my recent
tutorial at the Trilogy summer school on "practical microeconomics
and Internet resource sharing protocols" here:

<

http://inl.info.ucl.ac.be/tutorials/tfiss09-briscoe>

When I get to slides 22 & 23 at the very end of Pt1, I explain
this properly.

In addition, who will be
charged? The sender? The receiver?

Again, this isn't up to me or the IETF - it's up to each ISP. I
believe we should provide metrics so that either sender (re-ECN) or
receiver (ECN) can be made accountable for congestion.

Having said that, I have strong concerns about making the receiver
accountable for congestion or for anything related to usage at the
network layer (whether volume or congestion-volume), because receivers
ultimately can't control what is sent to them (due to DDoS). I.e. in the
above example, I would recommend counting only sent congestion (re-ECN)
against the allowance, not received (ECN).

D, In addition, the new
technique deployment problem, need all the devices to support it.

Not at all. Like ECN, re-ECN is designed to be permanently partially
deployed by some networks, some senders and some receivers.

* Network: each network that wants to have congestion exposed can
deploy ECN independently of other networks and deploy policing at its
trust boundaries.

- Not all forwarding equipment can do ECN today - fine if it
drops instead, esp if it's not frequently congested

* Sender: there's a distinction between re-ECN & non-re-ECN
packets - a sender can choose which it sends.

- a network that is policing based on re-ECN info is also
likely to rate-limit non-re-ECN packets; loosely at first to encourage
hosts to upgrade, then more strictly once there's no excuse for hosts not
to have upgraded.

* Receiver: a re-ECN sender works OK with an ECN receiver now. If you
upgrade the receiver it works more precisely though.

I'm not saying it will be easy (there will probably be firewalls that
block it etc), I'm just saying it's definitely been designed to be
incrementally deployable. And a lot of thought has gone into the
independent incentives of each stakeholder in order to deploy their piece
of the picture.

Another problem is charging. If
the access node should do the congestion charging, it makes the network
devices heavy. Is it proper for the cost
consideration?

I wouldn't recommend congestion charging - no-one likes it. We
designed re-ECN so we could do congestion policing instead. Nonetheless,
even if an ISP were congestion charging, it would be as easy as charging
for volume measured over a month - but instead you measure only the
volumes of marked bytes and ignore those not marked. That's just a dead
simple pair of counters like you do for RADIUS today.

The whole idea is to allow all the network devices to be simpler.
Rather than having all the resource scheduling and policing on every
forwarding device, they just do bulk ECN marking and re-ECN gets this
information to one device (policer) at the ingress so it can see all the
congestion the user is causing in the whole Internet. Policing can then
be done at that one device for the whole Internet at once. And the hosts
have the incentive to do all the scheduling correctly, rather than doing
scheduling in all the queues. You get a full QoS system with nothing but
ECN in the queues.

For instance, one aim is to be able to have all-optical interconnect
between domains. I imagine it would be feasible to do ECN in photonics,
but I suspect a hierarchical scheduler and policers would be much much
harder.

Another aim of re-ECN was to ensure ingress policer could be simple -
the simplest sufficient policer for re-ECN is much like a bulk token
bucket. However, my main concern on complexity is the device I call a
dropper that re-ECN needs at the egress (intended to ensure the sender
has no incentive to lie about re-ECN). That also does minimal processing
per packet, BUT it requires per-flow state.

My PhD thesis has all the pseudocode for each of the devices, and
summary tables of instructions per packet and memory usage etc. I can
send if you're interested, <

http://www.bobbriscoe.net/pubs.html#refb-dis>

altho I'd rather finish the report version I'm preparing which will
be much shorter (perhaps 80pp instead of 256pp).

a, The network is open. It is
difficult to let the network device to be a police, to control all kinds
of service of the user strictly. The more illumination, the more
temptation. The improvement of the user experience would be more proper
to be placed in the application level.

This has been the whole point of my last 10yrs of research: to find
the minimal policing necessary to ensure as much freedom and openness as
possible, but only restricting those who excessively restrict the freedom
of others (which excessive congestion represents). Thus giving the right
incentives to the app and transport layer to improve everyone else's user
experience.

This 6pp workshop paper is a good summary of the policing
approach:

<

http://www.bobbriscoe.net/projects/refb/#polfree>

b. It should not be very often
that the network congestion occurs. If so, that means that the network
needs to expanse its capacity. Even the congestion in the flash cloud
(peak time) should not be very serious; otherwise the network needs to
expands its capacity.

I disagree. If there's not congestion somewhere along a path, it
means the transport protocols are broken. Each elastic flow should be
able to go fast enough to cause the onset of congestion. If not, it will
only complete later than it could have done.

ECN breaks the link between the two - you get congestion signals but
minimal congestion delay or jitter and very nearly zero loss.

The rule of thumb about keeping utilisation low comes from focusing
on core networks, not on the whole path. I'm talking about the whole
internetwork. But once we can break the link between congestion and
impairment, core networks won't need to be congestion-free either. Not
necessarily persistently congested - periods of ECN congestion signals
then silence.

Another argument: it should be possible to have any empty capacity
always filled by scavenger data. Then a low background level of
congestion signalling means the network is always being fully used, but
as soon as any non-scavenger data comes along, the scavenger transports
should yield, nearly as if the network had been empty.

c, use the existing technique,
take good use of flow classification in the egress of each SP, the egress
of each special telephone line user; for the up streaming traffic for
individual user, except to give the packets for dedicated device (e.g. IP
telephony) corresponding priority, put the rest in BE queue.

d, through some simple technique, to assure the all or most of the
users' experience of inelastic flow (audio,
video).

Above I've been talking about the wider problem of fair management of
*all* traffic. Yes, we have worked out ways to get VoIP working without
solving the wider problem - either without in-network QoS mechanisms
because VoIP's not very demanding anyway, or with in-network QoS for
carrier-grade assurances as you mention. But the latter with in-network
QoS has still proved too complex to get much inter-domain deployment,
except for demonstrators. Given we had VoIP working over ARPAnet, that's
pretty pathetic.

By approaching the problem of fair management of *all* traffic (with
re-ECN), it turns out that you get inter-domain QoS as a neat (and rather
valuable) side-effect. In theory, ECN keeps all the queue short with v
low queuing delay & jitter and hardly any loss - for all traffic.
Then re-ECN does the sharing out of capacity, which deals with the
bandwidth allocation dimension. And the congestion exposed in packets
gives all the right metrics inter-domain accounting, by just locally
counting marked bytes crossing the border. And the API is "just go
faster if you want" - there's no prior permission required, whether
setting up a Diffserv SLA or flow signalling or anything.

Just my two
cents.

and my twenty.

Cheers

Bob

B. R.

Tina

----- Original Message -----

From: Bob Briscoe

To: re-ECN unIETF list

Cc: Ingemar
Johansson S

Folks,

More views welcome?

CEX

ConEx

re-con

C-IT (pron.
"See it") for Congestion Information Transparency.

ambiguous with ECN's "Congestion Experienced (CE)"
tho.

Bob

Bob
Briscoe,
Networks Research Centre, BT Research

re-ECN mailing list

[email-masked]

Bob
Briscoe,
Networks Research Centre, BT Research

Bob
Briscoe,
BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 02 Oct 2009 18:39:29 +0100

Phil,

At 18:05 02/10/2009, [email-masked] wrote:
>Agree with you joe.
>
>One of the barriers to investment is that 
>increasing capacity may not lead to better e2e 
>qos (because the problem is somewhere else). By 
>exposing information about congestion, it should 
>be easier to assign blame correctly about where 
>the bottleneck is - and therefore improve the 
>incentive to invest in more capacity (I can tell 
>you're a good guy, so shift my traffic to you - 
>you gain by getting the connection etc charge).
>
>Maybe that sounds a rather indirect argument - 
>but given there are incentives to invest in 
>capacity today, I think better information about 
>the bottlenecks should help the incentives to invest.
>
>The obvious counter-example is where a consumer 
>has only one choice of local provider and then 
>indeed it does seem that the ISP can make "more 
>money because their network is congested". But 
>the problem here is that the ISP has a 
>termination monopoly, which basically needs to 
>be tackled by regulation in some shape or form - 
>there is exactly the same issue today.

Actually, you can create technical solutions to 
remove termination monopolies. See mail to Stuart 
Venters that I just sent in this same thread.

Bob

>To: Eardley,PL,Philip,DEE1 R; 
>[email-masked]; 
>[email-masked]; [email-masked]