Subject: [re-ECN] Name for BoF?

From: Bob Briscoe <[email-masked]>
Date: Mon, 07 Sep 2009 23:21:08 +0100

Folks,

One important issue I never raised - the name.

Congestion Exposure
Congestion Visibility
Congestion Transparency

I've had people who hate the word transparency, as it's ambiguous 
wither you can see it or not.
Exposure sounds more active than visibility, so I've gone with that 
at the moment. But any strong objections, speak now!

And a short form:
CEX?
re-ECN?

I'm undecided - some people should have heard of re-ECN, which 
favours that one.
CEX sounds like something you can only want more of ;)

Bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: Soo-Hyun Choi <[email-masked]>
Date: Mon, 7 Sep 2009 23:28:32 +0100

> One important issue I never raised - the name.

Vote for Congestion Exposure.

> I've had people who hate the word transparency, as it's ambiguous wither you
> can see it or not.
> Exposure sounds more active than visibility, so I've gone with that at the
> moment. But any strong objections, speak now!
>
> And a short form:
> CEX?
> re-ECN?
>

Maybe, CEX as re-ECN could be one of them.

Cheers,
Soo-Hyun

UCL Computer Science
http://www.cs.ucl.ac.uk/staff/S.Choi

> I'm undecided - some people should have heard of re-ECN, which favours that
> one.
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
>

---

From: João Taveira Araújo <[email-masked]>
Date: Tue, 08 Sep 2009 00:08:40 +0100

Bob Briscoe wrote:
> Exposure sounds more active than visibility, so I've gone with that at 
> the moment. But any strong objections, speak now!
>
> And a short form:
> CEX?
> re-ECN?

re-con? I don't really like shoving ECN in the mix as it seems to imply 
reinserting ECN is the only way of revealing congestion, which may not 
be the case in the future. Plus recon ties in with the military meaning. 
Either way this discussion isn't that important before BoF. TANA/LEDBAT 
also figured out the name post-BoF if I remember rightly.

Joao.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 08 Sep 2009 09:03:28 +0100

Folks,

More views welcome?

Summary of 'votes' so far...

>>One important issue I never raised - the name.

Congestion Exposure seems to get everyone's approval

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

---

From: Tina TSOU <[email-masked]>
Date: Tue, 08 Sep 2009 16:17:10 +0800

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

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

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

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

           CEX
           ConEx
           re-con

  Bob

---

From: <[email-masked]>
Date: Tue, 8 Sep 2009 09:20:05 +0100

If you want to go for something catchy I had been thinking on the lines of:

ExCeTra (pronounced etc.) - EXposing Congestion TRAnsparently

I am exactly split between Congestion Transparency and Congestion Exposure. Congestion Visibility is weak...

Toby

PS - glad we got something out in time for the deadline. Let's hope it proves suitable to get us to the starting gate in Hiroshima...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bob Briscoe
> Sent: 08 September 2009 09:03
> To: re-ECN unIETF list
> Cc: Ingemar Johansson S

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 8 Sep 2009 10:19:36 +0200

Probably my last effort

Transport with accountabiliy = Trac
Transport with congestion visiblity = Travis or Tracvis
  Not the Travis guy in "Taxi driver", of course he also wanted to clean up

Not that good but maybe it gives other ideas.

> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 8 september 2009 10:03
> To: re-ECN unIETF list
> Cc: João Taveira Araújo; Soo-Hyun Choi; Ingemar Johansson S
> Everyone agrees on what it shouldn't be: Not re-ECN Less 
> agreement on a replacement:
> 
>          CEX
>          ConEx
>          re-con
> I'm not so keen on including "Con" for obvious reasons :) 
> Choosing something like that can come back and bite you.
> codepoint) for rest-of-path congestion could be called CEX 
> (Congestion Expected), rather ambiguous with ECN's 
> "Congestion Experienced (CE)" tho.
> 
> 
> Bob
> 
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 8 Sep 2009 11:01:43 +0100

6 more suggestions:

Connexion - CONgestioN EXposure InformatiON
Context - CONgestion EXposed Truthfully
Convex - CONgestion Voluntarily EXposed
Counted - COngestion {UNiversally Truthfully} ExposeD
Exact - EXposing All CongesTion
Expect - EXPosing CongesTion

Of these I think I prefer exact, counted and context as the words convey something of what we mean.

Toby

> Behalf Of [email-masked]
> Sent: 08 September 2009 09:20
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked]
> Cc: [email-masked]
> I am exactly split between Congestion Transparency and Congestion
> Exposure. Congestion Visibility is weak...
> 
> Toby
> 
> PS - glad we got something out in time for the deadline. Let's hope it
> proves suitable to get us to the starting gate in Hiroshima...
>

---

From: ken carlberg <[email-masked]>
Date: Tue, 8 Sep 2009 06:10:02 -0400

Tina,

> 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 think its important to keep in mind that ECN itself only conveys the  
condition of near congestion somewhere along the path.  That  
information, sent back to the source, then triggers a reaction.  The  
form of that reaction is (from my perspective) open for discussion,  
but by default is assumed to be a reduction of the sending rate.  For  
TCP as a transport, the back-off algorithms are automatically  
triggered.  For voice/video that uses RTP/RTCP, one can have a more  
creative set of reactions because the near-congestive state  
information is pushed up to the application.

As a side note, there are a couple of draft RFCs on the topic of ECN  
support for RTP/RTCP and a joint presentation given at the AVT meeting  
in Stockholm -- minutes are available.  The authors of the drafts will  
pool their efforts into a single approach with a new draft to be  
issued before the Hiroshima IETF.

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

a good question.  My *guess* is that Bob would envision something like  
a future inter-domain variation of Pre-Congestion Notification as  
*one* approach to address this issue, but if not, its something to be  
kept in mind in the debate.

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

I don't understand your second question.  As for the first, there may  
not be a single answer.  In the case of TCP, one has the existing back- 
off algorithm as a baseline.  Bob has spoken in the past about not  
always having to be TCP-friendly, so perhaps other less aggressive  
algorithms (eg, that operate over longer periods) may be defined or  
promoted by the group.

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

its hard to provide an answer without a more precise definition of  
what you are considering a "device".  If its an end-point (eg, host),  
then it will have had to perform some form of end-to-end negotiation  
in agreeing to support ECN.  If its an intermediate node (router or  
middle box), then *ideally* non-support or non-recognition of the ECN  
field in IP *should* not matter because the packet should be forwarded  
with no additional action taken.  Unfortunately, there are devices and/ 
or SP policies that either zero out the ECN field or drop the packet.   
Hopefully, that will change with related efforts like the Homegate BoF  
and this proposed BoF that exposes this problem.

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

the above questions are interesting, but perhaps too specific at this  
time until we have some drafts and more direction as to what the BoF  
will take on in terms of its milestones.

cheers,

-ken

> 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

---

From: João Taveira Araújo <[email-masked]>
Date: Tue, 08 Sep 2009 13:12:53 +0100

> Of these I think I prefer exact, counted and context as the words convey something of what we mean.

I quite like EXACT, except that re-ECN seems anything but exact and it 
certainly doesn't expose "all" congestion. Maybe "EXposing Accountable 
CongesTion" would be less misleading, since routers would mark the 
packets they want senders to be held accountable for.

I was toying around with DISSECT (DIScloSure of Expected Congestion for 
Transparency). The meaning (wiki: the process of disassembling and 
observing something to determine its internal structure and as an aid to 
discerning the functions and relationships of its components.) seems 
appropriate considering we're trying to retrofit IP internals to make it 
less opaque.

Joao.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 08 Sep 2009 14:45:17 +0100

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>

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

[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

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?

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

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

From: Bob Briscoe

To: re-ECN unIETF list

Cc: Ingemar
Johansson S

Folks,

More views welcome?

CEX

ConEx

re-con

reasons :) Choosing something like that can come back and bite
you.

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

---

From: John Leslie <[email-masked]>
Date: Tue, 8 Sep 2009 12:48:39 -0400

Bob Briscoe <[email-masked]> wrote:
> 
> We need to write an FAQ...

   Not a bad start, Bob.

   Does anyone want to suggest other questions (that have been answered
on-list?

--
John Leslie <[email-masked]>