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

[Bob Briscoe <[e-mail]>]

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:[e-mail]>Bob Briscoe
>To: <mailto:[e-mail]>re-ECN unIETF list
>Cc: <mailto:[e-mail]>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:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research