Re: [re-ECN] ECN fundamentals pt2/2

["STUART VENTERS" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]On Behalf Of Bob Briscoe
Sent: Thursday, October 01, 2009 7:05 PM
To: Tina TSOU
Cc: Ingemar Johansson S; [e-mail]; re-ECN unIETF list
Subject: [re-ECN] ECN fundamentals pt2/2 (was: Re: Name for BoF?)


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> 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> 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:[e-mail]>  

To: re-ECN unIETF list <mailto:[e-mail]>  

Cc: Ingemar  <mailto:[e-mail]> 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 

[e-mail] 

https://www.ietf.org/mailman/listinfo/re-ecn




________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research