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

[Bob Briscoe <[e-mail]>]

Tina,

These are v important fundamental questions...

I've answered about half of your questions, the rest will have to wait until later - I have to go for now. But I'll send this lot so far now.

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:

Dear all,
I definitely have interested in this work. WRT the name of the BoF, I have got used to re-ECN.

That protocol will still be called re-ECN, we just need a name for the BoF that doesn't imply e are pre-supposing re-ECN is the answer (that's the truth, although it was so difficult to come up with something that fitted between all the cracks, that my guess is that it will be extremely hard to come up with an alternative).

 
Some understanding for the time being is following. Please correct me if I’m wrong.
1, ECN is solving network congestion problem by requesting the sender to lower the sending rate. In this way, if congestion occurs for inelastic flow (i.e. the traffic sensitive to delay and jitter, for example voice, video), how does ECN support this service?

I'll take sensitivity to delay/jitter and inelastic separately:

- delay/jitter: the idea is that once the network can encourage elastic transports to back off, as long as inelastic and elastic traffic are pooled together, all the elastic transports will keep queues small.

- inelastic: To be concrete, let's assume the user is policed to keep within a bulk congestion-volume allowance for all sent traffic. If the bit-rate is small (e.g. VoIP), and if congestion is low, the flow won't use up much allowance even tho it's unresponsive. If bit-rate, congestion or both are high (e.g. unresponsive streamed HD video through a residential network at peak time), the inelastic flow might use up the congestion allowance on its own. Then policing would drop enough packets to prevent an inelastic flow continuing - it would become garbage and the human would probably stop it.

The assumption that policing is in bulk isn't necessarily how things will go. But we're trying to see whether this most simple policing is at least adequate without anything more complicated.

This brief workshop paper talks explores this space.
Policing Freedom to Use the Internet Resource Pool, Arnaud Jacquet (BT), Bob Briscoe (BT & UCL) & Toby Moncaster (BT), Workshop on Re-Architecting the Internet (ReArch'08) (Dec 2008)
<http://www.bobbriscoe.net/pubs.html#polfree" rel="nofollow"> http://www.bobbriscoe.net/pubs.html#polfree>

We're getting some nice results from simulating policing of mixtures of flows - congestion policing is a nicer to TCP than rate policing. And elastic flows nicely compensate for inelastic ones, unless the inelastic flows are seriously out of order. End users will notice their elastic traffic is suffering if they use a lot of inelastic at the same time.

We're also investigating this as a way to encourage content-providers to do self-admission control of inelastic flows (an alternative to PCN - without flow signalling). We've found some other guys in BT doing video codec research assuming congestion accountability. They have designed a codec that gives better MoS (mean opinion score) than BT's Vision service currently offers and by slowly varying MoS throughout a video it gets 170% as many videos through BT's backhaul relative to a VBR codec. And 216% as many as the CBR codec that the service currently uses. It's not real-time coding though.

2, when the congestion occurs in the network devices in the aggregation network, the traffic causing this congestion come from many sources. Therefore even some sources have few traffic, they may also receive the congestion notification.

That's the neat thing about random bulk marking. If you contribute x% of the traffic when there's congestion, you get x% of the marking, because x% of the blame is yours. Even tho you contribute little traffic, you are still a little to blame for your traffic being there when there's congestion. It's proportionate blame, which is correct.

As the network is convergent, in the multiple SP case, even the bandwidth of all SP rented is not full, their video or voice service may occur congestion. Presumably they lease the same volume of bandwidth, it will appear that some SP has little traffic, will also receive congestion notification to lower their traffic. Should they lower the traffic (at this time the rented bandwidth of each SP is not full)?

The marking again distributes blame proportionately. It works best if the contract itself is based on congestion - this is sufficient to be incentive-compatible.

But if the contract for each SP isn't based on congestion, but on bit-rate, then you need a different contract. The most appropriate contract in the example you give would be what's called a "contract and balancing" mechanism:
- Each SP contracts to pay in advance for a certain share of the bandwidth (say SP_i contracts for share c_i = 10%). It also agrees to pay extra at the end of the month if the share of congestion it causes (p_i) is more than 10%, and it gets a refund if it causes less than 10% of the congestion.

[And06] proves that the SPs have no incentive to contract for a smaller share of the capacity than they expect to use as long as the balancing payments of all the SPs are at the same price and the sum of them all is zero. [There is a little problem tho - none of the SPs, only the network operator knows what the total congestion is - a mechanism is needed for the SPs to trust that the network operator isn't cheating.]

3, Regarding the issue of that the source reduces the sending rate, how much should be reduced? As the network interim device is only responsible to mark the congestion, the receiver sends the ECN notification. How to deal with this case?

It's up to the sender. That's the neat thing - everyone doesn't have to react the same. But if the sender reacts less, it continues wth a greater share of the capacity and therefore picks up a greater share of the congestion markings. If it keeps on doing this, it will quickly run out of allowance.

The easiest way to think about this is by imagining each source runs a TCP with a weight parameter (a weight of 3 would behave like 3 TCP flows, a weight of 3/4 gets 3/4 of what 1 TCP would get). Instead of reducing the window by 1/2 every ECN mark, the TCP with weight 3 will reduce to 1 - 1/(2*3) = 5/6. it will converge on a share as if it were 3 flows. Similarly, the 3/4 TCP reduces to 1 - 4/(2*3) = 1/3.

Importantly, you still get the fast dynamic response to congestion of TCP, but each can have different shares of the link, rather than all having to be equal. Then big flows can have a lower weight, and small flows a higher weight.

4, The SP who doesn’t support ECN can benefit from others who support ECN. If some SP does no reduce the rate after receiving ECN, he can benefit form those SPs who react to ECN. (In worse case, it can attack via ECN.)

That's why we did re-ECN, so people could be accountable if they don't respond to congestion.

But importantly, we allow people to choose whether they use re-ECN or not (packet by packet). We expect ISPs will rate limit non-re-ECN packets though. But I try to to be prescriptive on how ISPs will use all this.

 
Regarding re-ECN, there are issues above, but some more question.
A, In the network, not all devices support ECN, is it the case that in the congestion situation the packets sent by the devices who don’t support ECN will be discarded?

Y

B, In congestion case, if the network congests, a new sender sends packets, he will be fined to keep being discarding his sending packets. Should this unfairness be considered?

I don't completely understand the question.
B1/ First an answer assuming no loss, only ECN marking:

With re-ECN, you aren't fined for the congestion you experience (which you can't predict). You have to say what congestion you expect, then you are fined for that.

[And if you understate your expectations, the re-ECN dropper will punish you (I've proved that a simple dropper can be designed that ensures senders have no incentive to understate congestion).]

When a new source arrives, it doesn't know what congestion to expect. So re-ECN requires it to be conservative. It must use up at least one credit packet to get started, and every time there is a congestion event, it has to top this up to stay ahead. The idea is to shift the risk of starting a new flow to the flow, so it has an incentive to start carefullly.

Peter Key (Microsoft Research) [Key99] has shown that accountability for congestion creates the incentive to gradually start a flow, in fact exponentially (like TCP slow-start).

B2/ If the congestion is at a node that doesn't support ECN, the network operator can't enforce congestion control based on re-ECN (in fact no known scheme can). But if a network operator wants to deploy re-ECN to manage the congestion responses of its users, it will obviously ensure its routers have ECN turned on.

That doesn't really answer your quetsion, but I think it answers a question that is relevant...


Bob


References so far
=================
[And06] Anderson, E., Kelly, F. & Steinberg, R., "A Contract and Balancing Mechanism for Sharing Capacity in a Communication Network," Management Science 52:39--53 (2006)  URL: http://www.statslab.cam.ac.uk/~frank/aks.html" rel="nofollow"> http://www.statslab.cam.ac.uk/~frank/aks.html

[Key99] Key, P. & Massoulié, L., "User policies in a network implementing congestion pricing," In: Proc. Workshop on Internet Service Quality and Economics MIT (December 1999)  URL: <http://research.microsoft.com/research/network/publications/ISQElm.ps" rel="nofollow"> http://research.microsoft.com/research/network/publications/ISQElm.ps >

C, Each sender/receiver, apply/lease bandwidth before using the network. When the congestion occurs in the network, is it proper to recharge them? In addition, who will be charged? The sender? The receiver?
D, In addition, the new technique deployment problem, need all the devices to support it. It is a bit difficult to deploy. 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?
 
Some thoughts are following.
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.
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.
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).
 
Just my two cents.
 

B. R.
Tina
http://tinatsou.weebly.com/contact.html" rel="nofollow"> http://tinatsou.weebly.com/contact.html
 
 
 
 

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

From: Bob Briscoe

To: re-ECN unIETF list

Cc: 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

[e-mail]

https://www.ietf.org/mailman/listinfo/re-ecn" rel="nofollow"> https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research