Subject: [re-ECN] Acronym for BoF / w-g?

From: Bob Briscoe <[email-masked]>
Date: Mon, 28 Sep 2009 19:32:18 +0100

Hi Congestion Exposers (or should that be ex-posers?),

Lars & Jari need an acronym.

Can someone suggest a way to decide between the 
ideas proposed so far below, rather than just 
going round and round on the list?

Context - CONgestion EXposed Truthfully
Counted - COngestion {UNiversally Truthfully} ExposeD
Exact - EXposing All CongesTion
Expect - EXPosing CongesTion
ExCeTra (pronounced etc.) - EXposing Congestion TRAnsparently
CEX - Congestion EXposure or Congestion Exposure eXperiments
ConEx - Congestion Exposure
re-ECN - re-inserted Explicit Congestion Notification (or receiver aligned)
re-con - Reinserted Congestion? Also alluding to military reconnaissance
Trac - Transport with accountabiliy
Travis or Tracvis - Transport with congestion visiblity

I've removed a couple the original proposer 
didn't really like, to try to start converging.

If we're voting, I vote for CEX (with a soft C of course).

Bob

>Subject: RE: [re-ECN] Name for BoF?
>Date: Tue, 8 Sep 2009 11:01:43 +0100
>From: <[email-masked]>
>To: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Cc: <[email-masked]>
>
>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
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of [email-masked]
> > Sent: 08 September 2009 09:20
> > To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [re-ECN] Name for BoF?
> >
> > 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
> > > 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
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/re-ecn
> > _______________________________________________
> > re-ECN mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Matthew Ford <[email-masked]>
Date: Mon, 28 Sep 2009 19:51:17 +0100

On 28/09/2009 19:32, Bob Briscoe wrote:
> Can someone suggest a way to decide between the ideas proposed so far
> below, rather than just going round and round on the list?

Pick one ;)

> Expect - EXPosing CongesTion

I like this one - it's not ludicrously contrived, and it's germane to 
the work (as in, you can tell how much congestion to ... expect)

> If we're voting, I vote for CEX (with a soft C of course).

Reminds me of the BT Security Evaluation and Certification Scheme 
(BTSECS) ... *shudder*

Mat

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 28 Sep 2009 14:52:29 -0400

I don't like any of them.  I propose CEEX (pronounced "seeks").

Choose your favorite acronym expansion, several will do.  Maybe:
congestion experience exposure or congestion experience explicit exposure.

If you don't like that, how about CEEEX?  Same pronunciation.

---

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 28 Sep 2009 15:35:27 -0400

I am worried the use of CEX and Exposure may 
generate too much traffic for the list.
It may also trigger some censorship with some jurisdictions and organizations.
What do you tell the immigration officer who checks your passport when he asks
you what convention/meeting you are attending 
before he lets you into the country?
We may have too many people attending our meetings.

I like C-IT (See It) for Congestion Information Transparency
I like Transparency more than Exposure, as 
Transparency hints at trust, while Exposure
hints at unwanted disclosure (like the publishing of movie star private info).

-- Kwok --

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Sep 2009 12:37:58 -0700

Sounds like IP over Large Public Data Networks, aka eye-plop-down. :-)

I personally would like to stay away from the term "transport", as it  
is ambiguous in context - this is the network layer, the transport  
layer is one up, and people frequently use the term "transport" to  
mean "the layer below the one I care about" - everything from "the  
fiber" to "http" depending on context. There is no need to bless the  
ambiguity.

I would also suggest staying away from "re-ecn" unless we are agreeing  
up front to implement that specific solution.

I would also avoid the term "truthfully", as this is all about  
configuration, and different rates call for different configuration.  
Consider for example discussed in http://www-video.eecs.berkeley.edu/Proceedings/INFOCOM2004/DATA04/37_4.PDF 
. The authors reported that with 90% confidence variation in delay  
(and therefore externally measured congestion) was less than 1 ms (and  
therefore externally measured congestion was nil), with the same  
confidence interval they saw "frequent" spikes on the order of 10 ms  
(TCP synchronization?), and in a few events saw variation in delay as  
high as 100 ms (probable routing events). We obviously don't want CE  
marks at 1 ms, the value at 10 ms is questionable (if it goes right  
back down, what's the point), but when it becomes sustained above a  
few ms there is an issue. If we set the marking threshold at <pick a  
mean queue depth 1..20 ms or a rate 90..99% of capacity> is it a more  
"truthful" value than if you picked the next lower or the next higher  
integer?

That brings me back to "congestion exposure" or "congestion exposure  
experiments".

My two yen...

On Sep 28, 2009, at 11:32 AM, Bob Briscoe wrote:

> Can someone suggest a way to decide between the ideas proposed so  
> far below, rather than just going round and round on the list?
>
> I've removed a couple the original proposer didn't really like, to  
> try to start converging.
>
>> To: <[email-masked]>, <[email-masked]>, <[email-masked] 
>> >

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Sep 2009 00:41:37 +0100

Kwok,

Can I suggest we don't start open season again on 
the name, but just focus on the acronym.

Until now we had consensus on the name 
(Congestion Exposure), just not the acronym. I 
understand your concerns about "exposure", but 
there were strong concerns about transparency being ambiguous.

Sorry I wrongly omitted C-IT. Consider it added to the candidate list.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Sep 2009 00:47:46 +0100

Folks,

I'm running a workshop the next two days. If a volunteer wants to 
take up Steve's suggestion below, pls do... I won't have time until Thu.

Bob

At 19:58 28/09/2009, Steven J Bauer wrote:
>>Can someone suggest a way to decide between the ideas proposed so far below,
>>rather than just going round and round on the list?
>
>One possibility I have used in the past is:
>
>http://www.surveymonkey.com
>
>Up to 100 responses, which should be adequate for us, is free.
>
>Survey design is very easy.  You might for instance have each name be ranked
>from 1 (strongly dislike) to 10 (strongly like).   You could also have an open
>response.  (Other forms of questions are possible as well.  Setup is probably
>25 minutes.
>
>-Steve

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Sep 2009 16:56:17 -0700

OK, folks. Here's a poll. I hapen to have a doodle account and have  
not set up a surveymonkey account, so if we're using mine, we use the  
one we've got. Setup took under two minutes.

http://doodle.com/p7fvfpfebtey4xvp

This doodle poll lists the options Bob gave us in email. You can  
select as many or as few as you like, but only do it once.

On Sep 28, 2009, at 4:47 PM, Bob Briscoe wrote:

>>> far below,

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Sep 2009 01:01:13 +0100

Fred,

>Sounds like IP over Large Public Data Networks, aka eye-plop-down. :-)

Maybe some time off would help :)

>fiber" to "http" depending on context. There is no need to bless the

I agree.

>up front to implement that specific solution.

Agree too.

>Consider for example discussed in 
>http://www-video.eecs.berkeley.edu/Proceedings/INFOCOM2004/DATA04/37_4.PDF 

I think Toby had in mind the sender reinserting a 
truthful expectation of what the network exposed. 
But you're right truth could be considered as a 
judgement on whether what the network exposed in 
the first place was real truthful congestion.

Overall, I'd agree whatever - I don't believe 
truth is a top level concept that we need in the 
title, even tho it's an important requirement to define for the work.

>That brings me back to "congestion exposure" or "congestion exposure

What about an acronym?
Do you think Kwok's concern over becoming a CEX pot needs heeding?

Bob

>>>To: <[email-masked]>, <[email-masked]>, <[email-masked] >

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Sep 2009 17:22:10 -0700

> Do you think Kwok's concern over becoming a CEX pot needs heeding?

Kwok has a point, but personally it doesn't bother me as much; this  
thread will probably be the longest thread on the topic, and it's not  
all that long. We could discuss come of the acronyms that have been  
proposed, and some that have made it through.

Personally, I think this is a case for the AAAAA. ATTYOB. Most of our  
real problems are BKAM. BTDTGTS.

AWHFY?

BTAICBW...

---

From: Richard Bennett <[email-masked]>
Date: Mon, 28 Sep 2009 17:38:37 -0700

My suggestion is "Predicting Congestion" or "precon". If you want to go 
Hollywood, you could even go with "precog", but there's something about 
"precon" that I find oddly appealing.

RB

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Sep 2009 17:48:50 -0700

On Sep 28, 2009, at 5:08 PM, Bob Briscoe wrote:

A nameless correspondent told [you] that...

> The Internet should also be able to connect machines next door to  
> each other together. They might have sub-ms RTTs. We shouldn't  
> prevent scaling to tiny RTTs. One workround is not to standardise a  
> timescale for smoothing the queue, but allow a queue to be  
> configured in the knowledge of whether it might have v short RTT  
> paths through it.

You sent this to me privately, but I'm am going to completely blow  
etiquette to the winds and reply publicly.

I agree with your correspondent. To my way of thinking, the term  
"congestion" has many possible "correct" definitions; the key thing is  
that that sessions related to one set of applications and/or users  
prevents another set of applications and/or users from doing something  
that they would otherwise reasonably expect. TCP Reno measures  
congestion by loss; CalTech FAST measures congestion by change in mean  
delay. If the re-ecn model is being applied to a class of traffic that  
is priority-queued and traffic above some rate is dropped, the only  
model I can make any sense out of is one that determines what fraction  
of a stated rate is currently in use. In an 802.11 network, one could  
discuss the collision rate perceived by the interface. And in your  
corespondent's case of a sub-ms RTT (which would be characteristic of  
a data center), I'm not sure what measure applies best. Maybe the  
percentage of the time a queue has something in it?

And then there is the question - is that aggregated by source address,  
as in the way a BitTorrent server (file source) behaves, or by  
destination address, as in how a BitTorrent client (file sink)  
behaves, or is it by individual sessions? Or should one maybe track  
all three and let any of them mark the packet?

Now imagine typical web service behavior - a datagram starts in a data  
center, crosses a fiber-optic backbone, enters my home through a  
broadband interface, and crosses my WiFi to my computer.

 From my perspective, each interface in the network is likely to apply  
its own congestion model, and therefore its own congestion measure.  
What is important to control is not the specifics of the measure, but  
the fact that someone along the way is feeling trodden upon, that the  
offending traffic appears to have the potential to prevent another  
"customer", for some definition of the term, from doing their thing.  
If we have reasonable measures - not "the same measures", but  
"appropriate measures for the class of congestion under consideration"  
- in each place, the right thing should happen. The congested  
interface should be able to declare its pain, and the implicated  
sessions should back off.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Sep 2009 02:30:34 +0100

Fred,

It was fine to say this on the list. I wasn't trying to protect the 
nameless correspondent. The only reason I responded off-list was so 
as not to send the acronym thread off into a side topic, when we have 
to focus on getting this BOF acronym sorted.

The side topic is important, and I agree with you.

Bob

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Sep 2009 10:15:49 +0200

Hi all,

I am not happy with all the acronyms. Regarding the meaning, I like 
Richard's "congestion prediction" most as the returned ECN feedback is 
just a hint to predict the congestion on the path. But I feel that the 
term "exposure" has already quite some consensus. Another option which 
is in line with CEX, CEEX, etc. would be

Explicit Congestion Exposure (ECE)

It can be seen in contrast to or as a complement to Explicit Congestion 
Notification (ECN). We already have Pre-Congestion Notification (PCN) as 
another variant in this style.

Regards,

    Michael

Bob Briscoe schrieb:
> I've removed a couple the original proposer didn't really like, to try 
> to start converging.
>

-- 
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: Michael Menth <[email-masked]>
Date: Tue, 29 Sep 2009 10:35:39 +0200

Hi again,

as I said already before, I like Richard's "prediction" quite much as 
the "inserted re-feedback" is just an estimate for the congestion on the 
path. Another adjective to describe the congestion prediction would be 
nice to sound good, e.g., downstream congestion prediction (DCP) which 
also implies that proxies may insert re-feedback. Maybe another 
adjective is better?

Regards,

    Michael

Michael Menth schrieb:
> It can be seen in contrast to or as a complement to Explicit 
> Congestion Notification (ECN). We already have Pre-Congestion 
> Notification (PCN) as another variant in this style.
>
> Regards,
>
>    Michael
>
> Bob Briscoe schrieb:

---

From: <[email-masked]>
Date: Tue, 29 Sep 2009 09:50:23 +0100

Just one more suggestion (a variation really...):

Context - CONgestion EXposed (with "ext" = "ex'ed")

> Sent: 28 September 2009 19:32
> To: re-ECN unIETF list
> Subject: [re-ECN] Acronym for BoF / w-g?
>

---

From: <[email-masked]>
Date: Tue, 29 Sep 2009 09:57:51 +0100

I am not convinced that prediction is quite right. To me it implies a particular approach (namely re-ECN) and I am keen that any WG is given the freedom to eventually explore other possible approaches.

Having said that I am also not completely convinced by "expose" or "Exposure" (preferring instead transparency with its associated economic context). However, as Bob said in an earlier email we seem to have converged that as being the word that causes least confusion.

Sadly whatever you choose to call something is always open to misinterpretation...

Toby

> Behalf Of Michael Menth
> Sent: 29 September 2009 09:36
> To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Cc: re-ECN unIETF list
> Subject: Re: [re-ECN] Acronym for BoF / w-g? DCP
> 
> Hi again,
> 
> far

---

From: <[email-masked]>
Date: Tue, 29 Sep 2009 10:01:58 +0100

Perhaps an alternative name for re-ECN itself could be:

INSPECT - Insertion of predicted congestion

Toby

> Sent: 29 September 2009 09:58
> To: [email-masked]; Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Cc: [email-masked]
> I am not convinced that prediction is quite right. To me it implies a
> particular approach (namely re-ECN) and I am keen that any WG is given
> the freedom to eventually explore other possible approaches.
> 
> Having said that I am also not completely convinced by "expose" or
> "Exposure" (preferring instead transparency with its associated
> economic context). However, as Bob said in an earlier email we seem to
> have converged that as being the word that causes least confusion.
> 
> > >>> > If you want to go for something catchy I had been thinking on
> the
> > >>> lines
> > >>> > of:
> > >>> >
> > >>> > > From: [email-masked] [mailto:re-ecn-
> [email-masked]]
> > On
> > >>> > > Behalf Of Bob Briscoe
> > >>> > > reasons :) Choosing something like that can come back and
> bite
> > you.

---

From: <[email-masked]>
Date: Tue, 29 Sep 2009 10:10:16 +0100

And one more:

TECI - Timely Exposure of Congestion Information - pronounced "techy"

The main thing this adds is the idea that it is important WHEN this info is exposed...

However I am mindful of the extremely sound advice in RFC5434 which tells us that a common pitfall for BoFs is 

" - giving the BOF a "cute" but unintuitive name (or acronym),
    preventing people from realizing that it would be of interest to
    them."

Toby

> Sent: 29 September 2009 09:50
> Subject: Re: [re-ECN] Acronym for BoF / w-g?
> 
> > > > PS - glad we got something out in time for the deadline. Let's
> hope
> > it

---

From: Tina TSOU <[email-masked]>
Date: Tue, 29 Sep 2009 17:11:11 +0800

Toby,
I have the same feeling as yours.

B. R.
Tina

http://tinatsou.weebly.com/contact.html

  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, September 29, 2009 4:57 PM
  Subject: Re: [re-ECN] Acronym for BoF / w-g? DCP

  Toby

  > >>> hope it

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Sep 2009 12:17:45 +0300

Please, guys. We need less acronym proposals and more decisions. I  
really don't care much what the acronym is, as long as it's a bit  
longer and hopefully a bit more mnemonic than two characters.

We should really be discussing the BOF agenda and proposed WG charter  
instead of over-optimizing the acronym.

Lars

---

From: <[email-masked]>
Date: Tue, 29 Sep 2009 10:36:41 +0100

As Lars points out we do need to get our priorities straight here (and I
know I am as guilty as anyone of prolonging this discussion...).

My suggestion would be to set up a new doodle with the 3 most popular
choices from the current poll and see if we can converge on an acronym
by tomorrow. Alternatively I would be perfectly happy for Lars to just
choose one of them for us...

Meanwhile I will start 2 new threads to try and sort out a draft agenda
(making an assumption that we get 2 hours of meeting time) and to try
and get the draft charter discussions started again...

Toby

> From: Lars Eggert [mailto:[email-masked]]
> Sent: 29 September 2009 10:18
> To: Moncaster,T,Toby,DER3 R
> Cc: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked]

---

From: <[email-masked]>
Date: Tue, 29 Sep 2009 10:58:30 +0100

As promised, here is the start of a discussion on the draft agenda for
the BoF... This is making the assumption that we will get 2 hours of
meeting time. I personally feel 2 hours is plenty - if we got more than
that the risk is that we will lose the focus (and lose our audience).

5 mins      administrivia
10 mins     introduction by chairs
20 mins     the problem
15 mins     towards a solution
10 mins     demonstration
40 mins     discussion
10 mins     sumnmary
10 mins     questions and hums

Details: 

"The problem" will give the background to why we want to do this work,
and why now. It will probably be split into two halves - the general
problem for the Internet and the specific problem as seen by an
operator. It should largely cover the first half of the problem
statement document we are jointly working on.

"towards a solution" will cover the second half of the problem statement
document. It will describe an overview of re-feedback and show how this
can allow congestion to be exposed by end-users. It WON'T have details
of re-ECN itself, however it could explain briefly the concept of
policing to a congestion rate.

The "demonstration" should really take 5 mins, but allowing 10 mins
allows for things going wrong. At the moment the plan is to show a
simple re-ECN system where a series of different size files are
transferred across a link. At the BoF end there is a monitor that will
display the congestion level. We will be able to insert extra congestion
and show that the monitor can give you the congestion upstream and
downstream. The idea is to show that this is not just research but that
it is ready for the IETF - we aren't trying to impose our solution, we
just need to show that there is a solution possible...

The "discussion" will need to be led by the chairs to prevent it going
off into protocol details or other dead-ends. The key thing is to work
towards getting agreement that the CONCEPT of exposing congestion (and
thus correcting the information asymmetry) is a good thing, and that it
is the starting point towards a more open and transparent means of
controlling the use of the Internet by monitoring the one thing that
actually impacts all users... One of the key things here will be to show
there is already an active community working in this area.

"summary" just needs to bring together any loose ends from the
discussion and try and leave people with a clear set of messages, for
instance: congestion is a key metric, currently congestion is hidden
from the layer that needs to know about it, revealing this congestion
will correct the information asymmetry and lead to better control of the
Internet, etc

"The questions" will need a whole email thread of their own, but that
can wait till a bit nearer the day. The key thing is to have very clear
closed questions- that is questions that only have a yes or no answer...

Toby

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Sep 2009 15:06:51 +0200

Hi Toby and all,

the problem I have with most of the names so far is that they do not 
express the fact that we would like to quantify the congestion further 
down the path, i.e. not the congestion on the upstream of a flow but on 
the downstream of a flow is exposed or predicted. I proposed "Downstream 
Congestion Prediction" becdause the word "prediction" already expresses 
the fact that something is estimated before it occurs.

However, I am perfectly happy with the term "congestion exposure" if we 
could compensate the deficiency mentioned above by adding something like 
"Downstream Congestion Exposure - DCE".

Regards,

    Michael