Subject: [conex] Comments on draft-ietf-conex-concepts-uses

From: Nandita Dukkipati <[email-masked]>
Date: Tue, 19 Jul 2011 20:25:04 -0700

Hi. Following are my comments on conex-concepts-uses draft -- as an
individual contributor.

First of, the draft shows a marked improvement over the previous version and
has made forward progress. Good work on this front! But there is still
plenty of room for improvement so here it goes -

The high order bits:

1. I like the fact that the draft focusses on one killer Conex application
which is traffic management; the remaining ones are nice-to-have use cases.
The structure that Alissa Cooper proposed looks promising in bringing this
feature out more explicitly.

2. The draft starts out reading fresh, focussed and promising but the
quality deteriorates significantly as we go further on into Sections 5, 6,
7.

3. The language used throughout seems a bit too casual for an Internet
Draft. There's significant amount of work to be done in terms of tidying up
the writing.

4. There was one thing that I was really looking forward to and didn't find.
There are two main ideas necessary to get across the Conex idea - a)
congestion volume matters, and b) knowing about "rest-of-path" congestion or
downstream congestion matters. The draft brings out point (a) clearly, but
surprisingly there is very little on (b). I find that most folks new to
Conex get point (a) quickly and then are stuck thinking about why one would
ever need downstream congestion.
------------

Nits in individual sections:

1. Figure 1: Can be made simpler to parse without sacrificing information.
Has too many arrows currently.

2. Sec. 2
“The blame for congestion...”
Accountability for congestion sounds better than blame. I know there's
extensive discussion on this in a separate thread...

3. Sec. 2
The introduction part of Sec. 2 (preceding the definitions in Sec. 2.1) is
wordy/rambling and I don’t see what its primary purpose is. It also ends
rather abruptly. However, the good parts are the examples; they add a _lot_
of clarity.

The definitions in Sec 2.1 by themselves do a great job of introducing key
Conex concepts. My suggestion would be to jump in straight to the
definitions and move some of the intro. text of Sec. 2 (and examples) to
after the definitions - then it serves to nicely connect the different
concepts.

4. Sec 3.1
"All of these current approaches suffer from some general limitations.
First, they introduce performance uncertainty...."
"Second, none of the approaches is able to make use of...."

Switch order of the first and second reasons, as the second one is by far
the most important shortcoming of existing traffic management schemes.

5. Sec. 5.1
“the only reason their networks work as a commercial concern is that...”
You mean commercial success?

6. Sec 5.3.  Consequence: User-Controlled Intra-Class Quality of Service
(QoS)
This section is wordy and rambling - need a simpler way of directly getting
to the point. QoS part was quite bad in previous drafts and it continues to
be here.

7. Another Consequence: Preventing Congestion Collapse.
I see the point that you are getting at, but this a very strong claim with
extremely little detail to back it up.

8. Sec. 6. Deployment Arrangements
The list of bullet points is not that helpful. Needs some thought on how one
can articulate the deployment part without relying too much on the
mechanisms draft.

9. Sec. 7
The Section should be named 'Potential Issues' - keeps the section focussed
on real issues as opposed to those which are non-issues.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 20 Jul 2011 18:29:02 +0100

Nandita,

At 04:25 20/07/2011, Nandita Dukkipati wrote:
>First of, the draft shows a marked improvement over the previous 
>version and has made forward progress. Good work on this front! But 
>there is still plenty of room for improvement so here it goes -
>
>The high order bits:
>
>1. I like the fact that the draft focusses on one killer Conex 
>application which is traffic management; the remaining ones are 
>nice-to-have use cases. The structure that Alissa Cooper proposed 
>looks promising in bringing this feature out more explicitly.

I was about to say the opposite to Alissa. Alissa's structure gives 
the "Other Use-Cases" a section each. I had deliberately kept them to 
bullet points within a section, because I wanted the reader to go 
away remembering one thing - this is primarily about improving 
traffic management with knock-on effects for LEDBAT & intra-class QoS.

The rest is icing on the cake - not even icing - just little silver balls.

>2. The draft starts out reading fresh, focussed and promising but 
>the quality deteriorates significantly as we go further on into 
>Sections 5, 6, 7.

OK.

>3. The language used throughout seems a bit too casual for an 
>Internet Draft. There's significant amount of work to be done in 
>terms of tidying up the writing.

OK, but some examples will help me know what you call casual.

>4. There was one thing that I was really looking forward to and 
>didn't find. There are two main ideas necessary to get across the 
>Conex idea - a) congestion volume matters, and b) knowing about 
>"rest-of-path" congestion or downstream congestion matters. The 
>draft brings out point (a) clearly, but surprisingly there is very 
>little on (b). I find that most folks new to Conex get point (a) 
>quickly and then are stuck thinking about why one would ever need 
>downstream congestion.

If we focus on drop-only ConEx for initially deployment (ie without 
much/any ECN), ConEx gives whole path congestion, but not really 
downstream congestion. Downstream congestion relies on ECN as well as 
ConEx. And for single-network scenarios, whole path is probably sufficient.

So, although I also think we should explain downstream congestion, it 
will only really get used briefly on the "Other use-case" of interconnection.

Having said that, I want to improve that part of Concepts (section 2) 
about the split between upstream & downstream congestion, so this is 
a useful prompt.

>1. Figure 1: Can be made simpler to parse without sacrificing 
>information. Has too many arrows currently.

Ug. We've had a huge amount of discussion about this diag, and I 
thought we'd reached consensus. So now we have one individual 
contributor breaking the consensus who happens to also be the chair, 
whose role it is to call consensus ;)

So I'm going to ask you to say more specifically what you don't like, 
and why everyone else is wrong ;)

>2. Sec. 2
>"The blame for congestion..."
>Accountability for congestion sounds better than blame. I know 
>there's extensive discussion on this in a separate thread...
>
>3. Sec. 2
>The introduction part of Sec. 2 (preceding the definitions in Sec. 
>2.1) is wordy/rambling and I don't see what its primary purpose is. 
>It also ends rather abruptly. However, the good parts are the 
>examples; they add a _lot_ of clarity.
>
>The definitions in Sec 2.1 by themselves do a great job of 
>introducing key Conex concepts. My suggestion would be to jump in 
>straight to the definitions and move some of the intro. text of Sec. 
>2 (and examples) to after the definitions - then it serves to nicely 
>connect the different concepts.

Without the prose at the start of S2, I felt the definitions suddenly 
slapped you in the face, without saying why you needed to know them 
or how they related to the introduction you had just read.

I can't find it now, but someone said the addition of this text was 
welcome in a document that claimed it was about concepts.

>4. Sec 3.1
>"All of these current approaches suffer from some general 
>limitations. First, they introduce performance uncertainty...."
>Switch order of the first and second reasons, as the second one is 
>by far the most important shortcoming of existing traffic management schemes.

OK.

>5. Sec. 5.1
>"the only reason their networks work as a commercial concern is that..."

Surely "work as a commercial concern" = "succeed commercially".
I assume you don't mean we should change this to "work as a 
commercial success". I'm not sure what you are saying.

>6. Sec 5.3.  Consequence: User-Controlled Intra-Class Quality of Service (QoS)
>This section is wordy and rambling - need a simpler way of directly 
>getting to the point. QoS part was quite bad in previous drafts and 
>it continues to be here.

Actually, I didn't change it except for the heading. But I can have a 
go (or a volunteer?).

>I see the point that you are getting at, but this a very strong 
>claim with extremely little detail to back it up.

Would it help just to add a caveat that this is believed to be true, 
but there is little evidence to back it up?

>8. Sec. 6. Deployment Arrangements

see new thread -->

>9. Sec. 7
>The Section should be named 'Potential Issues' - keeps the section 
>focussed on real issues as opposed to those which are non-issues.

The idea was to talk about things that might be issues, explain why 
they might be, but also why they might not be.

This is defensive writing. People could otherwise skim and think "X 
is a potential issue with ConEx" when actually the section says it 
probably isn't.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Nandita Dukkipati <[email-masked]>
Date: Sat, 23 Jul 2011 11:32:10 -0700

Bob,

> I was about to say the opposite to Alissa. Alissa's structure gives the
> "Other Use-Cases" a section each. I had deliberately kept them to bullet
> points within a section, because I wanted the reader to go away remembering
> one thing - this is primarily about improving traffic management with
> knock-on effects for LEDBAT & intra-class QoS.
>

The appeal in Alissa's proposed structure is its sections explicitly titled
"Core Use Case" and "Other Use Cases". Can't make it more direct than that
as to what the main use case is and what the others are - it's all there in
the section headings!

> 4. There was one thing that I was really looking forward to and didn't
> find. There are two main ideas necessary to get across the Conex idea - a)
> much/any ECN), ConEx gives whole path congestion, but not really downstream
> congestion. Downstream congestion relies on ECN as well as ConEx. And for
> single-network scenarios, whole path is probably sufficient.
>
> So, although I also think we should explain downstream congestion, it will
> only really get used briefly on the "Other use-case" of interconnection.
>
> Having said that, I want to improve that part of Concepts (section 2) about
> the split between upstream & downstream congestion, so this is a useful
> prompt.
>

Without getting into drop-only/ECN Conex, how would you explain to someone
the basic question - what is the fundamental reason that a network node
experiencing congestion requires to know the whole path congestion as
opposed to just its local congestion volume for some granularities of
traffic? Put in another way, if every node in the network is aware locally
of the congestion volume for some traffic granulaties (through some means
other than Conex), why wouldn't this suffice for congestion management?

We have discussed this question before... but I just have to wonder if the
answer is so obvious that it doesn't figure in the draft or is there some
other reason?

Nits in individual sections:
> Ug. We've had a huge amount of discussion about this diag, and I thought
> we'd reached consensus. So now we have one individual contributor breaking
> the consensus who happens to also be the chair, whose role it is to call
> consensus ;)
>
> So I'm going to ask you to say more specifically what you don't like, and
> why everyone else is wrong ;)
>
>
As I said, this is a nit. There's consensus on it, so let's leave it as is.

Would it help just to add a caveat that this is believed to be true, but
> there is little evidence to back it up?
>

That doesn't help at all. If we can't find a good reason to back it up, we
shouldn't have this point here.

> The idea was to talk about things that might be issues, explain why they
> might be, but also why they might not be.
>
> This is defensive writing. People could otherwise skim and think "X is a
> potential issue with ConEx" when actually the section says it probably
> isn't.
>

ok, makes sense.

Nandita