Subject: [conex] draft-ietf-conex-concepts-uses: New Intro text

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Jun 2011 17:20:45 +0100

ConEx folks,

After the last IETF in Prague, we agreed to work on a revised 
draft-ietf-conex-concepts-uses. We're planning on using a lot of the 
text as is, but we suggested that the Introduction needed a complete 
re-write. Below is our joint proposal.

Please bash.

Rationale for this Introduction:
===============================
* The main change is a shift to the main target use-case in the body 
of the document: traffic management, leaving defining congestion etc 
to the definitions and concepts section (section 2).
* Introduce enough of the solution to allow the reader to grasp the main logic.
* Introduce one primary use and mention there are others - to keep 
focused but hint at breadth.
* Start to weave in some benefits bullet points (transparency, neutrality).
* Hint at controversies like the over-provisioning issue in the first 
para, but leave addressing this to later, when we can go into the 
subject properly.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
1.  Introduction

    The power of Internet technology comes from multiplexing shared
    capacity with packets rather than circuits.  Network operators
    usually provide sufficient capacity, but whenever too much packet
    load meets too little shared capacity, congestion results.
    Congestion appears as either increased delay, missing packets or
    packets explicitly marked with ECN [RFC3168].  The classic Internet
    architecture is arranged so that receivers detect such signs of
    congestion and feed them back end-to-end.  Then, ideally, most
    senders reduce their rate in response.

    The purpose of this document is to motivate a new congestion exposure
    (ConEx) field at the IP layer.  The idea is to add a third pass to
    the feedback loop so that the sender can relay congestion information
    back into the internetwork layer, exposing the level of congestion
    the sender expects packets to experience along their whole path
    (Figure 1).  Then certain network nodes can use this new information
    at the IP layer, for example as input to traffic management.

    ,---------.                                               ,---------.
    |Transport|                                               |Transport|
    | Sender  |                                               |Receiver |
    |         |<==Feedback=Path==============================<|         |
    |     ,---|<--Transport Layer returned Congestion Signal-<|<--.     |
    |     |   |                                               |   |     |
    |     |   |                                               |   |     |
    |     |   |             ,-----------.                     |   |     |
    |     |   |             |(Congested)|                     |   |     |
    |     |   |>=Data=Path=>|  Network  |>=====Data=Path=====>|   |     |
    |     |   |             |  Device   |>-Congestion-Signal->|---'     |
    |     |   |             `-----------'                     |         |
    |     `-->|>---------(new) IP layer ConEx Signal--------->|         |
    |         |        (Carried in Data Packet Headers)       |         |
    `---------'                                               `---------'

    Figure 1: Where the ConEx Protocol Fits in the Internet Architecture

    This document serves as the entry point to the set of ConEx
    documentation, giving the 'why' rather than the 'how'.  A companion
    document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech].

    The main aim of ConEx is to support evolution of alternatives to the
    proliferation of traffic management solutions that are over-
    constraining, non-transparent and often not application-neutral.
    Traffic management ought to be able to leave end systems free to
    choose how to behave without undue interference, while simultaneously
    satisfying the main concern of network operators; to control traffic
    from some users that excessively limits the freedoms of others.

    Freedoms only actually collide when shared capacity becomes
    congested--when a link is full so that a greater share for one user
    would necessarily leave less for someone else.  Current traffic
    management solutions typically limit volume or bit-rate in order to
    reduce the likelihood of congestion--limiting one thing in the hope
    it might limit another.  However, there is no real need to count
    volume that is sent when there is no congestion, and there is no real
    need to limit bit-rate when there is no congestion.

    ConEx markings on packets add the missing information network
    operators need to get a handle on congestion itself.  Then they can
    directly limit and control traffic based on how much it contributes
    to congestion and leave traffic unconstrained if it doesn't cause
    congestion.  The idea is for the operator to be able to count and
    control the bulk volume or bit-rate of packets marked for congestion
    and disregard packets not contributing to congestion.

    With ConEx there is no need for the network provider to identify
    specific applications or behaviours at the flow level, because the
    relevant bulk congestion information is revealed at the network
    layer.  Also, because ConEx information is added explicitly at the IP
    layer, it is visible to provider and consumer alike.  Therefore
    traffic contracts or acceptable use policies can be based on a metric
    that is transparent to both parties and is sufficient to manage
    traffic without extra non-transparent wriggle-room and caveats.

    In summary, ConEx is designed to make it simple to do traffic
    management that is transparent, neutral and not over-constrained.
    Although there is no implication that network operators ought to
    provide such an unconstrained, transparent, neutral service, it
    certainly should not be impossible and ideally it should be the
    simplest service to provide.

    The IP layer is intended to engender new applications and behaviours
    and to work over all existing and new lower layer technologies.
    ConEx is a generative technology in this vein, with a range of
    potential uses.  This document focuses initially on traffic
    management before widening out to introduce some additional important
    uses for ConEx as well as brifly mentioning a few others.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Bob Briscoe & Rich Woundy

---

From: Michael Menth <[email-masked]>
Date: Tue, 14 Jun 2011 18:56:43 +0200

Hi Bob,

Am 14.06.2011 18:20, schrieb Bob Briscoe:
>    back into the internetwork layer, 
I think "IP layer" is more concrete

> exposing the level of congestion
>    (Figure 1). 
I'd prefer if you integrate the Figure more into the text for describing 
Conex. This makes reading easier.

> Then certain network nodes can use this new information
>    layer. 
Better: IP layer?

> Also, because ConEx information is added explicitly at the IP
This sentence is a bit complicated. Can you simplify?

>    uses for ConEx as well as brifly mentioning a few others.

I like this text about conex. However, I am not sure if one can fully 
follow if one doesn't have the "conex background".

Regards,

     Michael

> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Jun 2011 19:03:54 +0100

Michael,

Tx for the quick turn-round.

Everything you suggest makes sense. I have pasted replacement paras 
in the thread below to satisfy these requests.

At 17:56 14/06/2011, Michael Menth wrote:
>>draft-ietf-conex-concepts-uses. We're planning on using a lot of 
>>the text as is, but we suggested that the Introduction needed a 
>>complete re-write. Below is our joint proposal.
>>
>>Please bash.
>>
>>* The main change is a shift to the main target use-case in the 
>>body of the document: traffic management, leaving defining 
>>congestion etc to the definitions and concepts section (section 2).
>>* Hint at controversies like the over-provisioning issue in the 
>>first para, but leave addressing this to later, when we can go into 
>>the subject properly.
>>
>>
>>
>I'd prefer if you integrate the Figure more into the text for 
>describing Conex. This makes reading easier.

1st two paras again:

    The power of Internet technology comes from multiplexing shared
    capacity with packets rather than circuits.  Network operators
    usually provide sufficient capacity, but whenever too much packet
    load meets too little shared capacity, congestion results.
    Congestion appears as either increased delay, missing packets or
    packets explicitly marked with ECN [RFC3168].  The classic Internet
    architecture is arranged so that receivers detect such signs of
    congestion and feed them back end-to-end (shown at the middle and top
    of Figure 1).  Then, ideally, most senders reduce their rate in
    response.

    The purpose of this document is to motivate a new congestion exposure
    (ConEx) field at the IP layer.  The idea is to add a third pass to
    the feedback loop (shown at the bottom of Figure 1) so that the
    sender can relay congestion information back into the IP layer,
    exposing the level of congestion the sender expects packets to
    experience along their whole path.  Then certain network nodes can
    use this new information at the IP layer, for example as input to
    traffic management.

>>    relevant bulk congestion information is revealed at the network

Done

>This sentence is a bit complicated. Can you simplify?

I've edited it to:
    Although there is no implication that network operators ought to
    provide such an unconstrained, transparent, neutral service, it
    certainly should not be impossible. Ideally it should also be the
    simplest service to provide.

>I like this text about conex. However, I am not sure if one can 
>fully follow if one doesn't have the "conex background".

Would it be better if we explicitly permit the reader to not 'get it' 
just by reading the Introduction.

For example in para 2 we could add:
"The purpose of this doc is to ++outline the concepts necessary to 
understand and++ motivate a new congestion exposure (ConEx) field at 
the IP layer"

And further down:
"  The ++rather radical++ idea is for the operator to be able to count and
    control the bulk volume or bit-rate of packets marked for congestion
    and disregard packets not contributing to congestion."

?

Bob

>>Bob Briscoe & Rich Woundy

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Steve Bauer <[email-masked]>
Date: Tue, 14 Jun 2011 14:33:38 -0400

>   would necessarily leave less for someone else.

One part that caused me to wince was the discussion of "freedoms".  I
don't want to equate congesting a link with stomping on other's
liberty.   You must mean this in a technical sense, so I would use
language that is less loaded.

Or maybe you deliberately choose "freedom" here?  I do understand that
these paragraphs are getting to the core of the motivation...

I would have perhaps said "the main concern of network operators"  was
"to control traffic from some users that disproportionately cause
congestion."  And then maybe just strike the first sentence of the
following paragraph which also discusses "freedoms".

-Steve

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Jun 2011 19:55:43 +0100

Steve,

I see the problem - we tried to link back to the first mention of the 
word 'free', but the text could be misconstrued to mean freedom of 
information, freedom of speech, freedom of association etc, not just 
freedom at the traffic behaviour level.

How about:
"  Traffic management ought to be able to leave end systems free to
    choose how to behave without undue interference, while simultaneously
    satisfying the main concern of network operators; to control traffic
    from some users that excessively limits the freedom of others to send
    how they want.

    These freedoms only actually collide when shared capacity becomes
    congested...
"

Bob

---

From: Michael Menth <[email-masked]>
Date: Tue, 14 Jun 2011 22:06:27 +0200

Hi Bob,

>    These freedoms only actually collide when shared capacity becomes
I understand this paragraph only as I am in the meantime used to this 
special wording that is relatively far from technical.

Problems to catch the meaning can be: "without undue interference" is 
not necessarily clear what it means. Also the story with "freedom" and 
"freedoms collide" is quite metaphoric. I know now what this means, but 
it's not so easy for newbies.

Regards,

     Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 14 Jun 2011 22:10:20 +0200

Hi Bob,

Am 14.06.2011 20:03, schrieb Bob Briscoe:
> Everything you suggest makes sense. I have pasted replacement paras in 
> the thread below to satisfy these requests.
>
Great!

>
>
>>>    ,---------.                                               
>>> ,---------.
>>>    |Transport|                                               
>>> |Transport|
>>>    | Sender  |                                               
>>> |Receiver |
>>>    |         
>>> |<==Feedback=Path==============================<|         |
>>>    |     |   |                                               |   
>>> |     |
>>>    |     |   |                                               |   
>>> |     |
>>>    |     |   |             ,-----------.                     |   
>>> |     |
>>>    |     |   |             |(Congested)|                     |   
>>> |     |
>>>    |     |   |             `-----------'                     
>>> |         |
>>>    `---------'                                               
>>> `---------'

Also for the intro I prefer text that the user can understand quite 
well. Maybe parts of the content you want to bring in the intro would 
better fit into a conclusion?

>    control the bulk volume or bit-rate of packets marked for congestion
"marked for congestion" is not clear

Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 14 Jun 2011 22:50:46 +0200

Hi Bob,

I tried to simplify parts of your text - which is now certainly not 
general enough anymore. But maybe it inspires you for the intro.

Current traffic management solutions are not effective since they limit a
user's traffic based on the wrong quantities. E.g. volume caps or rate
limitations may not be strict enough in case of congestion while they
unnecessarily constrain the freedom of end systems in the absence of
congestion. Even worse, the methods may be not application-neutral and
non-transparent [whatever transparent means ...].

Traffic management solutions could be so much better if they had congestion
feedback from the network: access rates could be constrained when necessary
and high bitrates could be allowed when possible. Congestion exposure 
(ConEx)
aims to expose exactly that information to all IP nodes on a flow's path.
Congestion information consists of packets that are lost or re-marked, e.g.,
by ECN-re-marking, so that it is complete only at the destination. Since 
this
this is the quantity of interest, it needs to be feed back to the sender
which encodes it in consecutive packets of the same flow. Thus, ConEx
information reflects the conditions of the network of about one
round-trip-time ago. To allow any IP node to access ConEx information, it
must be coded in the IP header.

Your intro often uses an opposite strategy: it first gives a 
definition/statement then it explains what it is good for. I prefer to 
say first what the problem is and then how we aim to solve it. I find 
that easier to understand.

Best wishes,

     Michael

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Jun 2011 22:45:23 +0100

Michael,

>>At 17:56 14/06/2011, Michael Menth wrote:

[snip]

>>Would it be better if we explicitly permit the reader to not 'get 
>>it' just by reading the Introduction.
>
>Also for the intro I prefer text that the user can understand quite well.

Yes, I agree the reader must be able to understand everything they 
read in the order they read it. I meant that this is merely the 
introduction and the next section is about concepts and definitions, 
which is where understanding should really become more complete.

>  Maybe parts of the content you want to bring in the intro would 

Please be more specific. Are you disagreeing with our Rationale for 
the introduction (repeated below), or are you saying we have written 
more than the rationale requires us to write?

>>>>* Introduce one primary use and mention there are others - to 
>>>>keep focused but hint at breadth.
>>>>first para, but leave addressing this to later, when we can go 
>>>>into the subject properly.

>>understand and++ motivate a new congestion exposure (ConEx) field 
>>at the IP layer"
>>
>>And further down:

You haven't said whether these additions address what you were 
concerned about (if they don't I won't add them).

>"marked for congestion" is not clear

I've changed it to
"...control the bulk volume or bit-rate of packets with ConEx markings..."

(However, I originally avoided this because I was trying not to imply 
a particular mechanism).

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Jun 2011 22:49:50 +0100

Michael,

At 21:06 14/06/2011, Michael Menth wrote:
>>I see the problem - we tried to link back to the first mention of 
>>the word 'free', but the text could be misconstrued to mean freedom 
>>of information, freedom of speech, freedom of association etc, not 
>>just freedom at the traffic behaviour level.
>>
>>How about:
>I understand this paragraph only as I am in the meantime used to 
>this special wording that is relatively far from technical.
>
>Problems to catch the meaning can be: "without undue interference" 
>is not necessarily clear what it means. Also the story with 
>"freedom" and "freedoms collide" is quite metaphoric. I know now 
>what this means, but it's not so easy for newbies.

Perhaps you are taking the above out of context, because I didn't 
repeat the following text, which I think moves from abstract general 
freedom to more concrete freedom to do x and y.

"  These freedoms only actually collide when shared capacity becomes

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Jun 2011 22:58:00 +0100

Michael,

Yes, these two paras are better. There are some new problems, but I 
will try to work on them.

I am imagining the Intro still starts the same as proposed, and this 
text only starts after the 3rd para, replacing:

"  The main aim of ConEx is to support evolution of alternatives to the
    proliferation of traffic management solutions that are over-
    constraining, non-transparent and often not application-neutral...
etc
"

Or are you thinking your text starts the Introduction?

Bob

At 21:50 14/06/2011, Michael Menth wrote:
>and high bitrates could be allowed when possible. Congestion exposure (ConEx)
>by ECN-re-marking, so that it is complete only at the destination. Since this
>definition/statement then it explains what it is good for. I prefer 
>to say first what the problem is and then how we aim to solve it. I 
>find that easier to understand.
>
>Best wishes,
>
>     Michael
>
>

---

From: Michael Menth <[email-masked]>
Date: Wed, 15 Jun 2011 07:58:42 +0200

Hi Bob,

Am 14.06.2011 23:49, schrieb Bob Briscoe:
>> not necessarily clear what it means. Also the story with "freedom" 
>> and "freedoms collide" is quite metaphoric. I know now what this 
>> means, but it's not so easy for newbies.
>
>    it might limit another.
in order to ... ->

in the hope it reduces the likelihood of congestion.

>   However, there is no real need to count

Newbies need to know that "freedom" is basically the traffic profile 
allowed by an ISP. Or even something more complicated. This text 
possibly defines that implicitly by using the word freedom in this 
context, but it does not define it clearly enough.

Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 15 Jun 2011 07:58:46 +0200

Hi Bob,

> Or are you thinking your text starts the Introduction?

No

Michael

---

From: Michael Menth <[email-masked]>
Date: Wed, 15 Jun 2011 07:58:54 +0200

Hi Bob,

Am 14.06.2011 23:45, schrieb Bob Briscoe:
>> well.

One can say here is the problem and that's the solution. Or one can say: 
that's a new mechanism which could solve that problem. For me the first 
approach is simpler, but your outline is of course also doable.

I believe that the major challenge for a newbie in the text is the set 
of used metaphoras and implicit definitions/formulations which are 
partly quite dense in the sense that they are almost conclusions. That 
was an obstacle for me in the very beginning of ConEx. Being more 
explicit facilitates reading.

>>>>> Rationale for this Introduction:
I'm not quite sure what you mean by that. Probably "change" with respect 
to the existing draft, right?

>>>>> * Start to weave in some benefits bullet points (transparency, 
I am not sure what you mean by transparancy. Also neutrality could be 
briefly explained in this context.

>>> understand and++ motivate a new congestion exposure (ConEx) field at 
The purpose of this doc is to point out current problems in traffic 
manament that are due to deficiencies of today's Internet architecture. 
We argue that a new congestion exposure (ConEx) field at the IP layer 
could provide valuable information for innovative solutions to that problem.

> concerned about (if they don't I won't add them).

My concern was more that the text is excellent for people who are used 
to ConEx language but it may be difficult to read for others.

> (However, I originally avoided this because I was trying not to imply 

This formulation probably avoids the particular mechanism and points out 
the difference to existing solutions:

The rather radical idea is for the operator to be able to do traffic 
manament based on congestion feedback from the network. While existing 
mechanisms provide such information only to the source of a flow, ConEx 
makes it accessible to each node on a path.

Michael

---

From: "Mcdysan, David E" <[email-masked]>
Date: Wed, 15 Jun 2011 09:13:50 -0400

Bob, Rich,

This is an improved introduction. The ASCII art illustrating the nesting
of control systems derived from the Mathis/Briscoe presentations on the
mechanism draft is most helpful in communicating the overall context and
structure of the mechanism, and I assume that a version of this figure
will also be placed in the mechanism draft.

IMO, the introduction needs to explain at a high-level at least one major
benefit that will be seen by operators and end users. I would like to be
able to give the use case document to someone who is not familiar with
conex at all and they should be able to get this message from reading the
introduction alone. (They may not know from the introduction how these
benefits are achieved, but the summary of benefit(s) in the introduction
should be compelling enough to motivate the reader to continue reading
more of the document.) Scanning over other responses in the thread, I
believe that Michael Menth has made a similar comment. I include some text
for discussion in line below summarizing these benefits for discussion by
the working group.

Also, I think at some point in the document, the timescales over which
this third pass of the control loop operates and the high-level net effect
of congestion encoding needs to be described. I suggest at least inserting
the word "persistent"

Finally, the introduction mentions shared congestion, but at some point
the document needs to address the case when a single user is causing
congestion of a non-shared queue (e.g., a DSL/cable modem).

Thanks,

Dave

>Rationale for this Introduction:

(There are some rewrites proposed to the above, but a paragraph
summarizing some important benefits could fit here.)

An example benefit for an operator is discarding packets creating
excessive congestion at the ingress point where they are received from a
user, reducing the required network capacity between such ingress points
and the point where persistent congestion of shared capacity is occurring.
This also provides a benefit to end users when operator pricing reflects
this improved efficiency. Furthermore, end users with longer RTTs whose
throughput was reduced as compared with users with shorter RTT will see
improved throughput when persistent congestion of shared capacity occurs.

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 15 Jun 2011 14:40:34 +0100

NB, I am deliberately replying at this point in the thread, not to the
additional thread between Bob and Michael...

I personally agree with Steve that the word "freedom" is too emotive for
this document. It works well in presentations and can be used in purely
technical documents, but in a standard it runs the risk of being
misconstrued.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bob Briscoe
> Sent: 14 June 2011 19:56
> To: Steve Bauer
> Cc: ConEx IETF list
> Subject: Re: [conex] draft-ietf-conex-concepts-uses: New Intro text
> 
> Steve,
> 

I think this revised wording is OK as it is crystal clear what is meant by
freedom at this point...

>     These freedoms only actually collide when shared capacity becomes

This is where it gets a bit tricky "freedoms colliding" sounds awfully like
a political statement, not something technical standards related. There is
also the problem that when one skim reads a document something like this
leaps out at you because it is at the start of a para...

I would tweak this sentence to read something like:

"The problem comes when shared capacity becomes congested..."

That still carries the same meaning but without any potential for
misunderstandings. It also reads well with the remainder of that paragraph.

Toby

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 15 Jun 2011 14:46:21 +0100

Your new text is certainly a real improvement. In general I agree with most
of the tweaks that have been suggested. I am not sure about Dave's
suggestion of adding another paragraph about benefits--not because I think
it wouldn't fit, more that I think this is just about the right length for
an introduction as it stands.

I do have one slight worry. I know you want to make it clear how powerful
ConEx can be, but the penultimate two paragraphs have hints of tub-thumping.

Having said that, I may just be being over-sensitive and over-British in my
desire for restrained language!

Toby

> Of Mcdysan, David E
> Sent: 15 June 2011 14:14
> To: ConEx IETF list
> >* Introduce enough of the solution to allow the reader to grasp the
> main
> >logic.
> >    ,---------.                                               ,-------
> --.
> >    |     |   |                                               |   |
> >    |     |   |                                               |   |
> >    |     |   |             ,-----------.                     |   |
> >    |     |   |             |(Congested)|                     |   |
> >    |     |   |             `-----------'                     |
> >    `---------'                                               `-------
> --'

---

From: John Leslie <[email-masked]>
Date: Wed, 15 Jun 2011 17:39:41 -0400

>>>>>fully follow if one doesn't have the "conex background".

   Yesterday I started a word-smithing pass, and asked Michael for
clarification about some text he proposed.

   Today the day-job caught up with me. :^(

   Nonetheless, I think it worth posting my wordsmithing. It rewords
most of Bob's text "to ease the readers' task" (including simpler
sentence structure, avoiding some emotion-laden terms,  and moving some
follow-up details closer to the first mention); and it specifically
includes some of Michael's text (wordsmithed as well).

   If I may suggest: posting "I prefer <name>'s text" really isn't
helpful without adding a "because" clause.

   I reworked the Figure to have time consistently move downward.

   No doubt it could me shortened more -- this is still early in the
wordsmithing passes.

------------------------------- cut here -------------------------------
The power of Internet technology comes from multiplexing shared
capacity with packets rather than circuits. Network operators aim
to provide sufficicent capacity, but when too much packet load
meets too little shared capacity, congestion results.

Congestion may appear as increased delay, ECN [RFC3168] marking,
or dropped packets. Internet Congestion Control depends upon a
feedback loop where the receiving endpoint detects such signs,
feeds this detection back to the sending endpoint, and the sender
reduces the sending rate.

The purpose of this document is to motivate a new congestion
exposure (ConEx) field at the IP layer. The idea is to extend
the feedback to a complete loop, such that the sender marks as
'Congestion Expected' the level of congestion reported to it in
the next packet(s) it sends.

With this information, IP-layer network nodes can use this as input
to traffic management.

   +---------+             +-----------+                     +---------+
   |Transport|             | Congested |                     |Transport|
   | Sender  |             |  Network  |                     | Receiver|
   |         |=Data=Path==>|  Device   |======Data=Path=====>|         |
   |         |             |           |-Congestion-Signal-->|-->+     |
   |         |             .           .                     |   |     |
   |     +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+     |
   |     |   |             .           .                     |        |
   |     |   |             |           |                     |         |
   |     |   |=Data=Path==>|           |======Data=Path=====>|         |
   |     +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+     |
   |         |             .           .                     |   |     |
   |         |             .           .                     |(ignored)|
   |         |             |           |                     |         |
   +---------+             +-----------+                     +---------+

Current traffic management solutions are not effective at managing
congestion, since they limit a user's traffic based on the wrong
quantities. Volume caps and/or rate limitations may not be strict
enough in case of congestion, while in the absence of congestion they
constrain the end systems to a mediocre capability. If the network
operator tries to improve this mediocre capability, the traffic
management is no longer application-neutral and frequently obscures
the very problem network operators sought to fix.

Traffic management solutions could work so much better with feedback
about congestion at the IP layer: access rates could be constrained
when necessary and high bitrates could be allowed at other times.
Congestion exposure (ConEx) aims to expose exactly that information
to all IP nodes on a flow's path.

By having the sender ConEx-mark packets, the network operator sees
the congestion along the path of that flow one round-trip-time ago.
Thus the network operator can leave the task of balancing bandwidth
demands to well-behaved end-systems, while still having the tools to
control traffic from end-systems which don't respond appropriately
to congestion signals.

Network operators won't need to identify specific applications,
because the same information which applications should use to manage
congestion will be visible to network operators: thus it will be
clear whether applications (considered as a group) are responding
appropriately to congestion.

Because ConEx information is added explicitly at the IP layer, it is
visible to provider and consumer alike. Therefore traffic contracts
or acceptable use policies can be based on a metric that is
transparent to both parties and is sufficient to manage traffic
without extra non-transparent wriggle-room and caveats.

The IP layer is intended to enable new applications and behaviours
to work over all existing and new lower-layer technologies.  ConEx
is a generative technology in this vein, with a range of potential
uses.  

In summary, ConEx is designed to make it simple to have traffic
management which is transparent, neutral, and not over-constrained.
Although it is not our place to require traffic management to meet
those characteristics, this should be the simplest service to provide
(and should reduce support costs).
------------------------------- cut here -------------------------------

---

From: Michael Menth <[email-masked]>
Date: Thu, 16 Jun 2011 00:23:14 +0200

Hi Bob, hi John,

I believe the draft contains all relevant ideas. Maybe the order of the 
ideas could be changed a bit to shorten the text. Then there would be 
more room to explain the figure in more detail. What about the following 
order?

multiplexing = power of the internet
what's congestion
what's the problem with current traffic management to avoid congestion
what's needed to solve the problem
what's the idea of ConEx
Explanation of the figure
ConEx  is generative technology
new traffic management technologies based on conex may achieve
* transparency
* app neutrality
* not overconstrained
...
purpose of this document and maybe structure

Best wishes,

     Michael

Am 15.06.2011 23:39, schrieb John Leslie:
> Michael Menth<[email-masked]>  wrote:
>     If I may suggest: posting "I prefer<name>'s text" really isn't

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2011 10:21:00 +0100

Michael,

>in the hope it reduces the likelihood of congestion.

Done.

>context, but it does not define it clearly enough.

I am now writing a new couple of paras based on your reordering - 
I'll take into account that the word freedom wasn't clear.

However, altho calling it a traffic profile might be strictly 
correct, I think it would make people think of very specific 
technologies like Diffserv policers, drawing people's minds away from 
the many different constraints that are put on Internet traffic 
(limiting certain applications differently, fair queuing, volume capping etc).

But we don't want to say all that yet. Sections 3 & 5 already go into 
all the traffic management detail. In the introduction, we only need 
to give the overall logic so people will understand why exposing 
congestion might be an answer.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2011 10:49:17 +0100

>misunderstandings. It also reads well with the remainder of that paragraph.

I don't want to imply congestion (freedoms 
colliding) in itself is a problem - there's no 
problem until someone always comes off badly and 
someone else well. You will notice this is a 
major change from the -01 intro; we've focused on 
unsatisfactory traffic management as the problem, 
not congestion. The body of the doc describes 
solving traffic management as a benefit; it 
(correctly) doesn't have removing congestion as a benefit.

How about:

"Everyone's freedom to send how they want is not 
an issue unless shared capacity becomes 
congested—-when a link is full so that a greater 
share for one user would necessarily leave less for someone else."

(I don't want to lose the reference back to the 
previous para just for the sake of those that skim read.)

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2011 10:42:00 +0100

Michael,

At 06:58 15/06/2011, Michael Menth wrote:
>>>>Everything you suggest makes sense. I have pasted replacement 
>>>>paras in the thread below to satisfy these requests.
>>>>
>>the introduction (repeated below), or are you saying we have 
>>written more than the rationale requires us to write?
>
>One can say here is the problem and that's the solution. Or one can 
>say: that's a new mechanism which could solve that problem. For me 
>the first approach is simpler, but your outline is of course also doable.
>
>I believe that the major challenge for a newbie in the text is the 
>set of used metaphoras and implicit definitions/formulations which 
>are partly quite dense in the sense that they are almost 
>conclusions. That was an obstacle for me in the very beginning of 
>ConEx. Being more explicit facilitates reading.

Understood - we're dealing with them one by one.

>I'm not quite sure what you mean by that. Probably "change" with 
>respect to the existing draft, right?

Yes, I meant change from the -01 draft

>I am not sure what you mean by transparancy. Also neutrality could 
>be briefly explained in this context.

The text now introduces these terms as follows:

"... traffic management solutions [...] It is also hard or impossible 
for the operator to be open and transparent about what they will do 
and they are often not application-neutral."

Does that help?

>>>>"The purpose of this doc is to ++outline the concepts necessary 
>>>>to understand and++ motivate a new congestion exposure (ConEx) 
>>>>field at the IP layer"
>manament that are due to deficiencies of today's Internet 
>architecture. We argue that a new congestion exposure (ConEx) field 
>at the IP layer could provide valuable information for innovative 
>solutions to that problem.

OK. But it's not just problem -> solution. We need to warn people 
that there are new concepts too.

I think one of the reasons people don't get it is that they don't 
expect their existing set of basic concepts (like the usefulness of 
bit-rate and volume) to be challenged by an Internet-draft.

>My concern was more that the text is excellent for people who are 
>used to ConEx language but it may be difficult to read for others.
>
>>
>>(However, I originally avoided this because I was trying not to 
>>imply a particular mechanism).
>
>This formulation probably avoids the particular mechanism and points 
>out the difference to existing solutions:
>
>manament based on congestion feedback from the network. While 
>existing mechanisms provide such information only to the source of a 
>flow, ConEx makes it accessible to each node on a path.

We avoided saying 'to each node on the path' because this has made 
some people assume we require each node on the path to be changed in 
order to act on this new ConEx information. This is why the text 
talks about the IP layer rather than each node and it says "Then 
certain network nodes can use this new information at the IP layer, 
for example as input to traffic management."

Cheers

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2011 11:24:00 +0100

David, Rich,

[I've addressed Rich as co-editor directly, because there are a 
couple of things within that we hadn't discussed/agreed. But I think 
Rich is off-line at the mo, so I've kept this on-list.]

Inline...

>will also be placed in the mechanism draft.

Correct (it was already there in abstract-mech-01)

>for discussion in line below summarizing these benefits for discussion by

Yup, I think we're all agreed on having traffic management as the one 
major problem and the one benefit of ConEx in the Intro - Michael's 
mainly helping in identifying language/concepts/metaphors that people 
won't understand.

>of congestion encoding needs to be described. I suggest at least inserting

I was intending to propose that we introduce timescales in the 
Concepts section (S.2) when explaining congestion-rate and 
congestion-volume (which convolve congestion and bit-rate at queue 
timescales). Then we can explain that the resulting metric can be 
accumulated over longer timescales up to months and it still captures 
how 'good/bad' behaviour was at queue timescales.

[However I haven't discussed this approach with my co-editor.]

>congestion of a non-shared queue (e.g., a DSL/cable modem).

In the current structure, I have this as a new "Shared Congestion" 
sub-section under "Potential Issues". I thought it was confusing in 
the -01 draft to raise this issue in the Introduction [Rich, I 
thought of this new home for shared congestion after our discussion 
on moving some parts, but omitted to seek your agreement. Agree?].

I'll post the structural changes Rich & I are proposing once the list 
discussion on the Introduction starts to converge.

Bob

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 16 Jun 2011 12:35:05 +0100

inline

> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 16 June 2011 10:49
> To: Toby Moncaster
> Cc: 'Steve Bauer'; 'ConEx IETF list'
> Subject: RE: [conex] draft-ietf-conex-concepts-uses: New Intro text
> 
> the
> > >     from some users that excessively limits the freedom of others
> to
> > > send
> > >     how they want.
> >
> congested--when a link is full so that a greater

That seems a bit better as it makes it clear what you mean by "freedom".
Although I would be happy with that sentence, it could be even clearer if it
said:

"Everyone's freedom to send how they want is only an issue when shared
capacity becomes congested--when a link is full so that a greater share for
one user would necessarily leave less for someone else."

If people are worried about complex sentence structure you could write it:

"Everyone's freedom to send how they want only becomes an issue when shared
capacity becomes congested. When a link is full one user getting a greater
share necessarily leaves less for someone else."

> previous para just for the sake of those that skim read.)

Indeed - I wouldn't want you to lose it, so long as the back-reference can't
be misconstrued by the skim reader...

> > > > >   congested--when a link is full so that a greater share for
> one
> > > user

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Jun 2011 13:19:17 +0100

John,

Thanks for this. I'll try to use as much as I can. I've only managed 
to respond inline to a few paras, as I have to rush to a mtg...

...rest will follow later.

>the next packet(s) it sends.

This removes the pointers to where we are in the diag (that Michael 
asked me to add, and I agreed would help lost readers).

I don't think 'complete loop' is useful as people already think of it 
as a complete loop before ConEx. This also might make newbies think 
that the router that generates the congestion signal also always 
reads the ConEx signal.

"...to add a third pass to the feedback loop" says exactly what is 
happening, doesn't it?

>With this information, IP-layer network nodes can use this as input

We obviously have two different implicit y axes. You're thinking of 
time down the page, I'm thinking of layering. I think this shows we 
need to label both (layers and time).

I wouldn't say 'ignored' because that could imply everything else 
doesn't ignore ConEx. Also, that's pre-judging how ConEx is used.

I agree we could remove 'in data packet headers' because it's 
mechanism, but on balance I thought it might undertanding help to leave it in.

>document outlines the ConEx protocol mechanism [ConEx-Abstract-Mech].

have to go... more later...

Bob

---

From: John Leslie <[email-masked]>
Date: Thu, 16 Jun 2011 09:54:29 -0400

> asked me to add, and I agreed would help lost readers).

   Hmm... not sure what you mean... In any case, the reader would have
forgotten this text by the time s/he gets to the diagram.

> that the router that generates the congestion signal also always 

   I agree "loop" isn't the right word.

> "...to add a third pass to the feedback loop" says exactly what is 

   Perhaps in your mind... I don't think it conveys that to the reader,
though.

   We might try something more in line with "in both directions".
I think the point is that the added congestion signal needs to travel
in the same direction the data experiencing congestion traveled, and
needs to follow the whole path.

> need to label both (layers and time).

   Good catch! My Transport Layer Congestion Signal needs "=", not "-".
" 
"  |     +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+     |

   The reader expects time to be the downward Y-axis. Making it anything
else will tend to confuse the reader.

> doesn't ignore ConEx. Also, that's pre-judging how ConEx is used.

   I agree "ignored" isn't the right word. Perhaps "not used".

> mechanism, but on balance I thought it might undertanding help

   I don't agree. It's pure mechanism -- while "IP-layer" steers clear
of mechanism.

> have to go... more later...

   Thanks.

--
John Leslie <[email-masked]>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 16 Jun 2011 18:35:32 +0200

Hi,

just a quick comment to one specific sentense:

> congested -- when a link is full so that a greater
I don't have the problem with the word 'freedom' here. But I don't think the 
second part is right. It might be okay to have larger share than another user 
at one point of time. When you are e.g. using the Internet just once a month 
to watch this very import video, whereas the other user is downloading stuff 
he never gone watch all the time everyday.

Mirja

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 16 Jun 2011 17:43:10 +0100

> Of John Leslie
> Sent: 16 June 2011 14:54
> To: Bob Briscoe

Although the diagram could refer back. Personally, when I come across text
like this and there is a diagram, I feel the text should point to the
diagram, but should be clear enough to work for people that don't think in
pictures...

>    I agree "loop" isn't the right word.

Especially it isn't right as ConEx should work in transports where there is
no congestion feedback.

We do need to make it clear that no router needs to read the ConEx signal
(though any router should be able to if it so wishes)

>    Perhaps in your mind... I don't think it conveys that to the reader,

Surely at that point ConEx is feed-forward, not feedback? Otherwise it might
sound like you expect the receiver to acknowledge how much ConEx signal it
saw (which you might want as some sort of nonce for data validity, but isn't
part of the core ConEx signal).

I will try and think of a clearer way to express this. I know this won't
just slot straight into the text, but how about:

"Congestion control currently relies on the receiver informing the sender of
any congestion it has seen. The sender then responds to such congestion
indications in order to reduce the congestion. ConEx requires the sender to
state how much congestion it expects to cause by sending a "congestion
experienced" signal with any data it sends. This ConEx signal travels
unchanged through the network to the receiver and can be seen at any
intermediate routers or devices that choose to read it."

> needs to follow the whole path.

And the SAME path! i.e. it shouldn't be taking the slow path in routers.

> >>   |         |             .           .                     |   |
> >>   |     |   |             .           .                     |
> >>   |         |             .           .                     |   |
> >>   |         |             .           .
> |(ignored)|

I actually think BOTH diagrams are useful. Bob's diagram makes it clear
where ConEx fits into the existing congestion feedback architecture, while
John's diagram is useful for showing the delay in the signal. I would
suggest Bob's diagram is better for the introduction, but I would be keen to
have John's time-based diagram included somewhere (as it will make more
sense to those people who are used to such diagrams).

>    I agree "ignored" isn't the right word. Perhaps "not used".

"not used" is better, since there might be a need to have a check later on
(as I mentioned above), or at least paranoid end-systems might want to be
able to check it! However that still has an implication that other things do
"use" the signal.

>    I don't agree. It's pure mechanism -- while "IP-layer" steers clear

Agree with John - in data packet headers is mechanism. The key point here
(surely) is that the signal must be visible to devices that want to see it?
That sort of implies packet header, but only if you assume a packet-oriented
IP layer (and I personally think ConEx can apply in other architectures in
future)

Toby

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 16 Jun 2011 17:46:41 +0100

Bob isn't saying that no user can have a greater share than any other -- far
from it. The whole point of ConEx is that "flow fairness" makes no sense.

All Bob is saying is that, if the link is full then if one user increases
their data rate every other user has to decrease theirs (or suffer markedly
higher data losses). 

However the fact you find this confusing does suggest that Bob needs to
think of a clearer way to express this.

Toby

> Of Mirja Kuehlewind
> Sent: 16 June 2011 17:36
> To: [email-masked]
> Subject: [conex] Freedom, was: draft-ietf-conex-concepts-uses: New
> Intro text
> 
> Hi,
>

---

From: John Leslie <[email-masked]>
Date: Thu, 16 Jun 2011 13:43:01 -0400

Toby is _much_ better at reading Bob's mind than I am!

> intermediate routers or devices that choose to read it."

   Compare to (earlier in my wordsmithed text):
] 
] Congestion may appear as increased delay, ECN [RFC3168] marking,
] or dropped packets. Internet Congestion Control depends upon a
] feedback loop where the receiving endpoint detects such signs,
] feeds this detection back to the sending endpoint, and the sender
] reduces the sending rate.

   (I'm not recommending anything in particular, but I'd hesitate to
either add all Toby's words earlier or repeat nearly-identical text.)

> And the SAME path! i.e. it shouldn't be taking the slow path in routers.

   Does that belong in an Introduction?

]] +---------+             +-----------+                     +---------+
]] |Transport|             | Congested |                     |Transport|
]] | Sender  |             |  Network  |                     | Receiver|
]] |         |=Data=Path==>|  Device   |======Data=Path=====>|         |
]] |         |             |           |-Congestion-Signal-->|-->+     |
]] |         |             .           .                     |   |     |
]] |     +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--+     |
]] |     |   |             .           .                     |         | 
]] |     |   |             |           |                     |         |
]] |     |   |=Data=Path==>|           |======Data=Path=====>|         |
]] |     +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|-->+     |
]] |         |             .           .                     |   |     |
]] |         |             .           .                     |(ignored)|
]] |         |             |           |                     |         |
]] +---------+             +-----------+                     +---------+
]]        Figure 1: Where the ConEx Protocol Fits in the Internet
]]...
>> The reader expects time to be the downward Y-axis. Making it
>> anything else will tend to confuse the reader.
> 
> where ConEx fits into the existing congestion feedback architecture,
> while John's diagram is useful for showing the delay in the signal.

   I tend to disagree that "Bob's diagram makes it clear where ConEx fits
into the existing congestion feedback architecture":
] 
] ,---------.                                               ,---------.
] |Transport|                                               |Transport|
] | Sender  |                                               |Receiver |
] |         |<==Feedback=Path==============================<|         |
] |     ,---|<--Transport Layer returned Congestion Signal-<|<--.     |
] |     |   |                                               |   |     |
] |     |   |                                               |   |     |
] |     |   |             ,-----------.                     |   |     |
] |     |   |             |(Congested)|                     |   |     |
] |     |   |>=Data=Path=>|  Network  |>=====Data=Path=====>|   |     |
] |     |   |             |  Device   |>-Congestion-Signal->|---'     |
] |     |   |             `-----------'                     |         |
] |     `-->|>---------(new) IP layer ConEx Signal--------->|         |
] |         |        (Carried in Data Packet Headers)       |         |
] `---------'                                               `---------'
]  Figure 1: Where the ConEx Protocol Fits in the Internet Architecture

   (Of course, Toby _is_ much better at reading Bob's mind...)

   It confused me. "Architecture" brings up many visions, none of which
prepared me to think that the Y-axis represented "layer".

> I would suggest Bob's diagram is better for the introduction, but
> I would be keen to have John's time-based diagram included somewhere
> (as it will make more sense to those people who are used to such
> diagrams).

   I'm perfectly happy to _have_ a diagram showing "where ConEx fits
into Internet Architecture", but I'm doubtful this is it; and I think
it would need a lot of text to explain it: thus I'd avoid putting it
in the Introduction.

--
John Lelie <[email-masked]>

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 16 Jun 2011 21:26:36 +0100

> From: John Leslie [mailto:[email-masked]]
> Sent: 16 June 2011 18:43
> To: Toby Moncaster
> Cc: 'ConEx IETF list'

Certainly I wasn't thinking you could just add all my text without much
bashing. I knew I was repeating text from earlier, that's why I said it
can't just slot straight in. I was really just having a stream of
consciousness and found it easier to include the first half to give the
context for what I was saying...

>    Does that belong in an Introduction?

Almost certainly not... I was just making a point having got into some
debate about similar stuff in PCN. 

> ]] |         |             .           .                     |   |
> ]] |     |   |             .           .                     |
> ]] |         |             .           .                     |   |
> ]] |         |             .           .
> ]] |         |             |           |                     |

To me, Bob's diagram makes sense as a representation of the logical topology
of how ConEx fits. Effectively it is a plan view of the logical network,
with no such thing as layer. It just so happens that, because of how the
Internet has evolved, the transport deals with the feedback and so the top
of the loop represents a higher logical layer than the bottom of the loop,
but I would never have interpreted that as a layer diagram! To me it was
just an attempt to recreate this picture:

< http://spectrum.ieee.org/images/dec08/images/fair03.jpg >

NB Architecture is (to my mind) a rather over-used term when applied to
networks. I might claim to be an expert in network architecture but I am not
convinced I could explain what that meant to a complete layperson!

> it would need a lot of text to explain it: thus I'd avoid putting it

I think we are now hitting a (possibly insurmountable) problem - different
people view diagrams in different ways. To me (who started my life as a
civil and structural engineer, drawing and interpreting site plans) Bob's
diagram makes perfect sense. But having spent 8 years in the world of
networking John's diagram also makes perfect sense! I think we perhaps need
a 3rd party to express an opinion here

Toby

---

From: John Leslie <[email-masked]>
Date: Fri, 17 Jun 2011 10:14:24 -0400

Toby Moncaster <[email-masked]> wrote:
> [John Leslie wrote:]
>> 
>> I tend to disagree that "Bob's diagram makes it clear where ConEx
>> fits into the existing congestion feedback architecture":
>>]
> To me, Bob's diagram makes sense as a representation of the logical
> topology of how ConEx fits.

   (I'm not sure our typical reader thinks in terms of logical topology.)

> Effectively it is a plan view of the logical network, with no such
> thing as layer.

   I'm certain it's possible to explain it (though this doesn't quite
do it for me); and I have no objection to having such a diagram so
long as a sufficient explanation follows it.

> It just so happens that, because of how the Internet has evolved, the
> transport deals with the feedback and so the top of the loop represents
> a higher logical layer than the bottom of the loop,

   Thus, I take it, there's no intent that the Y-axis convey layer.
Looking at it long enough, I can see an outward spiral of feedback,
where the new ConEx signal adds another one-way-trip. I think removing
both "Carried in" and "Feedback=Path" would help, as well as balancing
whitespace above and below the "Data=Path". Also, it isn't good to
suggest that the new Conex signal somehow avoids going through the
congested network device.

   But even with those modifications, I think explanatory text will be
needed.

> ... To me it was just an attempt to recreate this picture:
> 

   (Did you forget a smiley, Toby?)

> NB Architecture is (to my mind) a rather over-used term when applied
> to networks. I might claim to be an expert in network architecture
> but I am not convinced I could explain what that meant to a complete
> layperson!

   I do believe we must write something an architectural-layperson can
understand.

> I think we are now hitting a (possibly insurmountable) problem -
> different people view diagrams in different ways.

   Agreed -- but I don't agree it's insurmountable...

> To me (who started my life as a civil and structural engineer, drawing
> and interpreting site plans) Bob's diagram makes perfect sense. But
> having spent 8 years in the world of networking John's diagram also
> makes perfect sense! I think we perhaps need a 3rd party to express
> an opinion here

   I've waited a bit to see if any third-party volunteered... but I
think once again that "I prefer <name>'s version" isn't helpful without
a "because" clause. As it stands, it's Bob's and Rich's job to try to
capture the "silent majority's" consensus.

   ;^)

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 17 Jun 2011 18:38:21 +0100

TOby,

Deliberately responding to the middle of the thread, inline...

>(though any router should be able to if it so wishes)

We don't even need to say the parenthesis.

>intermediate routers or devices that choose to read it."

That's pretty good. But again, I would deconfuse by simply saying:
s/intermediate routers or devices/IP layer devices/

>And the SAME path! i.e. it shouldn't be taking the slow path in routers.

Fast/slow path is mechanism.

Same path isn't absolutely necessary, as long as it's typical. Like 
packets of a flow, they can change path, but you don't want them to 
have to be pinned ONLY to one path. So I wouldn't bring path up here 
(this is introduction).

> > else will tend to confuse the reader.

I think John means "confuse readers who think like John"
My suggestion was to label the axis, so people don't have to guess. 
Then we don't have to continue this discussion.

If we discuss what "expected" congestion is, that should be under 
section 2, which we plan to re-title as Concepts, rather than just 
Definitions.

That's also where I promised David we would discuss the timescale 
subtelties of the congestion-volume metric.

>sense to those people who are used to such diagrams).

People expect a protocol timing diag to have diagonal lines.

Personally I don't think we should try to discuss protocol timing in 
concepts-uses. It's virtually impossible to talk about it in a 
mechanism-neutral way.

We have this in abstract-mech (I can't remember if it's in the 
published version or the next rev that has my updates and is sitting 
waiting for Matt to add his).

>able to check it! However that still has an implication that other things do

As I said once, saying "not used", "ignored" or anything here is 
pre-judging how ConEx is used by the receiver. This was deliberately 
left blank.

>IP layer (and I personally think ConEx can apply in other architectures in

Er, can we stay a little grounded here. This is the IETF, not the 
"Inter-Galactic Packet Network Standards Force".

For the IETF, "in the IP layer" means the same as "in IP packet 
headers". Because there is only IP payload and IP headers in the IP 
layer. And we're not putting ConEx in the payload.

In concepts-uses we are only not talking about mechanism in order not 
to pre-judge later decisions. There is no alternative  on the table 
other than signalling ConEx in data packet headers, so we can assume 
it. If we abstract for abstraction's sake, no-one will understand.

Bob

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 17 Jun 2011 19:15:23 +0100

> Sent: 17 June 2011 18:38
> Cc: 'John Leslie'; 'ConEx IETF list'

Indeed. I just wanted to make it clear to people reading this thread --
there are still people that believe ConEx requires every device to
understand it

> s/intermediate routers or devices/IP layer devices/

That is clearer and covers all sensible possibilities.

> Fast/slow path is mechanism.

OK, fair point. 

> have to be pinned ONLY to one path. So I wouldn't bring path up here

OK you're right that we don't want too much detail in an introduction. There
might be a need to discuss these sort of details in another document
(perhaps as an appendix?)

> 
> 
> 
> > >
> > > >>   +---------+             +-----------+                     +---
> ----
> > > --+
> > > >>   |         |             |           |-Congestion-Signal-->|--
> >+
> > > |
> > > >>   |         |             .           .                     |
> |
> > > |
> > > >>   |     +<--|<--Transport-.---Layer---.<--Congestion Signal-|<--
> +
> > > |
> > > >>   |     |   |             .           .                     |
> > > |
> > > >>   |     |   |             |           |                     |
> > > |
> > > >>   |     +-->|-->(new)--IP-.---Layer---.-Congestion Signal-->|--
> >+
> > > |
> > > >>   |         |             .           .                     |
> |
> > > |
> > > >>   |         |             .           .
> > > |(ignored)|
> > > >>   |         |             |           |                     |
> > > |
> > > >>   +---------+             +-----------+                     +---
> ----
> > > --+
> > > >>

Diagrams are always hard because people see them differently.

> section 2, which we plan to re-title as Concepts, rather than just

Yes, fair enough - expected needs actual explanation

> while

Agreed, that is a mechanism thing

> concepts-uses. It's virtually impossible to talk about it in a

I am actually not 100% sure you can avoid all mechanism and protocol details
whilst still having a concepts and use cases document that makes sense. I
know we have to ensure that the majority of mechanism is in abstract-mech,
but you may need a bit in order to explain the concept

> pre-judging how ConEx is used by the receiver. This was deliberately

OK, I have now looked back at your diagram and agree that it is much clearer
without this

> "Inter-Galactic Packet Network Standards Force".

I know!

> layer. And we're not putting ConEx in the payload.

So let's say "in the IP layer". As soon as you explicitly state in the
packet header you will get shouts of "mechanism" (though this is perhaps a
case in point where you will find it hard to excise all mechanism from this
document)

> it. If we abstract for abstraction's sake, no-one will understand.

I don't see how not specifying where the conex info is carried is going to
confuse? 

One key driver for keeping the mechanism out of this draft was that I got
told off by the WGCs for having mechanism in an earlier version...

Toby

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 23 Jun 2011 13:17:58 +0100

Toby, Mirja,

Point taken - I'll clarify. I won't suggest wording until I've 
absorbed all the emails I need to catch up on.

[Sorry for nearly a week's gap since I was last on-list. I was given 
a "little task".]

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 23 Jun 2011 16:06:34 +0100

Marcelo, Nandita,

Pls give guidance as wg chairs, so we don't write text you will later 
ask us to remove...

We (the editors) are having trouble with the requirement not to 
describe mechanism in conex-concepts-uses. People on the list seem to 
agree that some very high level description of ConEx mechanism is 
necessary in order to make sense of following text. The question is, 
where to draw the line.

Certainly, it is good discipline to be able to describe the problem 
without describing the mechanism of a solution. But concepts-uses 
covers more than the problem. It also has to describe central 
concepts. If we describe central concepts without some degree of 
mechanism description, it's going to be one of those weird documents 
that commits to nothing and becomes content-free. For example...

The list seems happy that something pirtched at the level of how the 
ConEx charter describes the mechanism is fine (plus a picture a bit 
like the first one in abstract-mech). But we seem to need more to 
support later text. For example:

1/ Timing
In the Concepts section (the new name for section 2 on Definitions) 
we plan to explain what we mean by 'expected congestion' by talking 
about the sender starting off signalling a conservative expectation 
of congestion when it has no info about the path, then once it gets 
e2e transport feedback, it can continually re-insert the feedback 
into the IP layer as its expectation of congestion.

2/ Headers
I prefer to say ConEx info is put in packet headers at the IP layer. 
Some argue we should just say "at the IP layer" without mentioning 
headers. I think it's clearer to mention packet headers.

My logic is that the rule against speaking about mechanism is 
primarily designed to avoid prejudging later mechanism documents. 
However, if abstract-mech is already settled on a decision, and if 
describing it in concepts-uses is essential background to explain a 
concept, I would rather just do that, than dance around in abstract-land.

Otherwise readers might imagine we could be talking about backward 
ICMP messages or something, and get confused.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 23 Jun 2011 21:21:06 +0100

Michael,

The order you suggest is the logical structure one would expect for a 
solution document, leading from problem to solution.

However, this doc describes the problem and the benefits of a 
solution that is a given (taken from abstract-mech). The solution is 
not intended to be derived from the problem statement.

I have written a doc about re-ECN in the past that digs deeper and 
deeper into problem after problem in order to give the logic for why 
the particular solution was chosen. But that's not the purpose of 
this doc. It's not explaining the solution, it's just introducing it 
where necessary for context.

Bob

At 23:23 15/06/2011, Michael Menth wrote:
>Hi Bob, hi John,
>
>I believe the draft contains all relevant ideas. Maybe the order of 
>the ideas could be changed a bit to shorten the text. Then there 
>would be more room to explain the figure in more detail. What about 
>the following order?
>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Jun 2011 10:15:04 +0100

John,

At 13:19 16/06/2011, Bob Briscoe wrote:
>To: John Leslie <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Cc: Michael Menth <[email-masked]>, ConEx IETF 
>list <[email-masked]>
>
>John,
>

[jumping to halfway thru where I left off commenting a few days ago...]

>>the very problem network operators sought to fix.

I like the first part (based on Michael's suggestion), but I don't 
understand what was implicit in your mind during the last sentence. 
There's no intrinsic reason why improving a mediochre capability will 
lead to non-app-neutrality. Also, what is the stuff about "obscuring 
the problem" hinting at?

Anyway, don't sweat this last sentence. I want to use Michael's whole 
contribution, because he spelled it out in simple baby-steps for the 
reader, which was good.

>>to all IP nodes on a flow's path.

I don't want to lose the part about satisfying operator's main 
concern for control. I want to make it clear is about a reasonable compromise:
"Traffic management ought to ... satisfying the main concern of 
network operators; to control traffic from some users ..."

I'll weave this back in somehow. See what you think when I post it later.

>>the congestion along the path of that flow one round-trip-time ago.

ConEx isn't meant to be an RTT late (anyway 1 RTT is TCP-specific, 
RTCP feedback might be 20 RTTs behind). ConEx represents the 
expectation, ie at any instant ConEx has signalled at least as much 
as actual congestion. But explaining this needs to be deferred to the 
next section on concepts.

>>control traffic from end-systems which don't respond appropriately

I hope you agree that the following change would give a more 
appropriate impression of the intent in the reader's mind:

s/...end-systems which don't respond appropriately to congestion signals./
  /...sites that excessively contribute to congestion./

Reasoning:
1) I'd rather not make it seem to be about identifying traffic from 
specific end-systems, which is nearly the same as specific flows. 
It's about the traffic coming in to a network from a site, whether 
that's one machine, a home network or an enterprise.
2) Not responding appropriately to congestion is only one of the 
reasons for an excessive contribution to congestion. The other main 
reason is sending loads of traffic during congestion (even if every 
source responds appropriately to that congestion). We should explain 
how congestion-volume correctly counts up the 'harm' from either of 
these behaviours.

However, this dual role will need careful explanation, so it needs to 
be in the Concepts section not here. For the Introduction, let's just 
use words that are general enough not to contradict what we will say later.

>>appropriately to congestion.

Again, responding to congestion is only half the story.

>>without extra non-transparent wriggle-room and caveats.

Yes, the addition of "non-transparent" makes the link back to 
transparency clearer. Nonetheless, given the word transparent is not 
well understood by some (e.g. Michael's comments) I suggested:
s/a metric that is transparent to both.../
  /a metric that is open and transparent to both.../

>>------------------------------- cut here -------------------------------

OK. Many of these are useful re-phrasings. I will now produce a new 
Intro based on these, and the other earlier comments.

Cheers

Bob

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Jun 2011 11:20:11 -0400

> Pls give guidance as wg chairs, so we don't write text you will later 

   This isn't a fair question. WGCs aren't authors; nor are they editors:
they call consensus.

> necessary in order to make sense of following text. The question is, 

   That will have to wait for an editors' pass -- then see what various
WG participants think. (That's why we pay the editors those big bucks!)

> that commits to nothing and becomes content-free.

   I agree with Bob, here.

> The list seems happy that something pitched at the level of how the 

  IMHO, that could go in a definition of "expected congestion"; or
the definition could merely state that the "expected congestion"
signaled before the first RTT completes is application-dependent.  

> headers. I think it's clearer to mention packet headers.

   IMHO, this is a distinction without a difference. I'd tend to leave
it out in a concepts/uses document, but I see no reason to call it
inappropriate.

> concept, I would rather just do that, than dance around in abstract-land.

   IMHO, abstract-mech should not be considered "settled" -- not because
_I_ mean to challenge anything in it, but because our charter prevents
sending it to the IESG for approval until after they act on the concepts
document.

> ICMP messages or something, and get confused.

   IMHO, the less said about mechanism in concepts/uses, the less we're
inviting such confusion. :^(

   (YMMV, of course.)

---

From: ken carlberg <[email-masked]>
Date: Fri, 24 Jun 2011 11:32:35 -0400

John,

>   This isn't a fair question. WGCs aren't authors; nor are they editors:

I would very respectfully, but strongly disagree.  WGCs are meant to be participants -- both as individuals and as chairs.  One will notice that chairs in other groups will qualify their statements to the list as "speaking as an individual" or "with my working group chair hat on" so that the audience knows the context of the statements.

I would very much appreciate seeing some input from the chairs on the list since this is where all the official work is being done.  I'm concerned about last minute statements made at meetings that cause a fair amount of work (equating to valuable time by authors) to be discarded.  

cheers,

-ken

---

From: "Toby Moncaster" <[email-masked]>
Date: Sat, 25 Jun 2011 21:39:15 +0100

I am not sure these are such contradictory views.

WGCs are first and foremost responsible for getting the WG charter items
completed to the satisfaction of the IESG. This involves calling consensus
in the WG, but can also involve cajoling authors, coercing reviewers or
challenging dissenters (sorry, couldn't resist the alliterative list...)

However WGCs are also members of the WG and have a legitimate interest in
the work of the WG. At times that may put them personally at odds with the
consensus of the WG, and at such times they need to make it crystal clear
whether they are expressing a view as an individual or as a WGC. They may
decide the conflict is such that they have to defer to the other WGC (one of
the main arguments for having co-chairs).

What is certain is that there is currently insufficient communication on the
ML from the chairs. I for one would be keen to avoid ever seeing a repeat of
the situation in Prague where the chairs suddenly turn on some of the
document authors without previously having expressed their concerns either
on or off list... 

Toby

> Of ken carlberg
> Sent: 24 June 2011 16:33
> To: John Leslie
> Subject: Re: [conex] Some mechanism in draft-ietf-conex-concepts-uses?
> 
> John,
> 
> I would very respectfully, but strongly disagree.  WGCs are meant to be
> participants -- both as individuals and as chairs.  One will notice
> that chairs in other groups will qualify their statements to the list
> as "speaking as an individual" or "with my working group chair hat on"
> so that the audience knows the context of the statements.
> 
> I would very much appreciate seeing some input from the chairs on the
> list since this is where all the official work is being done.  I'm
> concerned about last minute statements made at meetings that cause a
> fair amount of work (equating to valuable time by authors) to be
> discarded.
> 
> cheers,
> 
> -ken
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 25 Jun 2011 22:55:49 +0000

Hi Bob,

Sorry for the delay on sending comments!

>    traffic without extra non-transparent wriggle-room and caveats.

In the paragrah above it is mentioned that the network provider to
identify
specific applications or behaviours at the flow level, because the
relevant bulk congestion information is revealed at the network
layer.

However, according to RFC 6077, in multi-domain scenarios, due to the
non-cooperative nature of multi-domain  environments, it seems unlikely
that network flow state could be  avoided (up to a certain extend) given
the network's per-packet flow  rate instructions that would need to be
compared against variations  in the actual flow rate, which is
inherently not a per-packet metric.

For RFC 6077, see:
http://www.rfc-editor.org/rfc/rfc6077.txt

Is it possible to explain in the draft how the congestion control related
issues associated with multi-domain scenarios discussed in RFC 6077 are
solved/worked out?

Best regards,
Georgios

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 26 Jun 2011 09:35:30 +0200

Hi,

speaking as a WG co-chair
below...

> necessary in order to make sense of following text. The question is, 
so, having the use cases separated from the mechanism description is an 
artifact from the wh charter creation process.
Nevertheless, there are plenty of cases where use cases or applicability 
statements are described in different documents than the actual 
mechanisms, so, that should be feasible.
The wierd thing is our case is that we are supposed to deliver the use 
case document before the mechanism description.

I agree that in order to understand the use cases the reader needs to 
understand the actual mechanism.

So, i think we have several options here:

1- Since we have a mature mechanism document, we can simply rely on it 
to describe the mechanism and assume that reader will read the abstract 
mechanism before reading the use case document. We can even include a 
normative reference and even if we ship the use case document to the 
IESG first, both docs will have to be published together.

2- We can copy part of the mechanism defined in the mechanism draft into 
the use case draft, in order to make it more self contained. The problem 
with this is that these two docs needs to be highly coordinated, in 
order to avoid contradictions between the docs.

3- We can decide to merge the 2 documents. That would require us to talk 
to the iesg and convice them that this is the best approach, but if the 
WG feels this is the way to go, we can try it.

So, I think we can do any of these 3. So far we have been oscilating 
between 1 and 2, which falls within what is specified in the charter, 
which i guess would make our progress easier.

That being said, it is up to the wg to choose whic appraoch is better 
(or to suggest other approaches)

Speaking as an individual now, i believe that is easier and more 
practical to go for option 1. Assume that the reader has read the 
abstract mechanism and heavily reference it and talk about the mechanism 
as described in there. We should ship them both toghter to the IESG, 
even if they don't consider the mechanism one for publication until the 
use case has been through.

Regards, marcelo

> In the Concepts section (the new name for section 2 on Definitions) we 
> plan to explain what we mean by 'expected congestion' by talking about 
> the sender starting off signalling a conservative expectation of 
> congestion when it has no info about the path, then once it gets e2e 
> transport feedback, it can continually re-insert the feedback into the 
> IP layer as its expectation of congestion.
>
> 2/ Headers
>> > >Surely at that point ConEx is feed-forward, not feedback? 
>> Otherwise it
>> > might
>> > >saw (which you might want as some sort of nonce for data validity, 
>> but
>> > isn't
>> > >(as I mentioned above), or at least paranoid end-systems might 
>> want to
>> > be

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 26 Jun 2011 10:26:17 +0100

Marcelo,

Thanks for this.

There's another option between your options 1 & 
2, which I would like to argue for (and perhaps 
this is what you were really thinking of):

Option 1.5: Reference abstract-mech, but 
summarise (rather than copy) anything 
particularly relevant, so that concepts-uses is 
self-contained enough to be read first.

Reasoning: people don't want to read about a 
mechanism if they don't know why it might be 
useful. So we ought to make the 'why' doc the 
recommended entry-point. Then if that convinces 
them, they can read the 'how' doc for more details.

I don't like pure option 1 (heavily reference 
abstract-mech). If information elsewhere is 
critical to the understanding of a doc, I believe 
its poor writing style to use a bare reference to 
the other doc without at least a brief summary of the concept the reader needs.

[Nonetheless, I admit this is going to get 
unweildy, given concepts-uses has a section on 
partial deployment. That's very hard to talk 
about without extensive prior knowledge of the 
mechanism. But let's at least try it and see.]

Bob

At 08:35 26/06/2011, marcelo bagnulo braun wrote:
>>Pls give guidance as wg chairs, so we don't 
>>write text you will later ask us to remove...
>>
>>We (the editors) are having trouble with the 
>>requirement not to describe mechanism in 
>>conex-concepts-uses. People on the list seem to 
>>agree that some very high level description of 
>>ConEx mechanism is necessary in order to make 
>>sense of following text. The question is, where to draw the line.
>so, having the use cases separated from the 
>mechanism description is an artifact from the wh charter creation process.
>Nevertheless, there are plenty of cases where 
>use cases or applicability statements are 
>described in different documents than the actual 
>The wierd thing is our case is that we are 
>supposed to deliver the use case document before the mechanism description.
>
>I agree that in order to understand the use 
>cases the reader needs to understand the actual mechanism.
>
>1- Since we have a mature mechanism document, we 
>can simply rely on it to describe the mechanism 
>and assume that reader will read the abstract 
>mechanism before reading the use case document. 
>We can even include a normative reference and 
>even if we ship the use case document to the 
>2- We can copy part of the mechanism defined in 
>the mechanism draft into the use case draft, in 
>order to make it more self contained. The 
>problem with this is that these two docs needs 
>to be highly coordinated, in order to avoid contradictions between the docs.
>
>3- We can decide to merge the 2 documents. That 
>would require us to talk to the iesg and convice 
>them that this is the best approach, but if the 
>So, I think we can do any of these 3. So far we 
>have been oscilating between 1 and 2, which 
>falls within what is specified in the charter, 
>That being said, it is up to the wg to choose 
>whic appraoch is better (or to suggest other approaches)
>
>Speaking as an individual now, i believe that is 
>easier and more practical to go for option 1. 
>Assume that the reader has read the abstract 
>mechanism and heavily reference it and talk 
>about the mechanism as described in there. We 
>should ship them both toghter to the IESG, even 
>if they don't consider the mechanism one for 
>publication until the use case has been through.
>
>Regards, marcelo
>
>
>>Certainly, it is good discipline to be able to 
>>describe the problem without describing the 
>>mechanism of a solution. But concepts-uses 
>>covers more than the problem. It also has to 
>>describe central concepts. If we describe 
>>central concepts without some degree of 
>>mechanism description, it's going to be one of 
>>those weird documents that commits to nothing 
>>and becomes content-free. For example...
>>
>>
>>The list seems happy that something pirtched at 
>>the level of how the ConEx charter describes 
>>the mechanism is fine (plus a picture a bit 
>>like the first one in abstract-mech). But we 
>>seem to need more to support later text. For example:
>>
>>1/ Timing
>>In the Concepts section (the new name for 
>>section 2 on Definitions) we plan to explain 
>>what we mean by 'expected congestion' by 
>>talking about the sender starting off 
>>signalling a conservative expectation of 
>>congestion when it has no info about the path, 
>>then once it gets e2e transport feedback, it 
>>can continually re-insert the feedback into the 
>>I prefer to say ConEx info is put in packet 
>>headers at the IP layer. Some argue we should 
>>just say "at the IP layer" without mentioning 
>>My logic is that the rule against speaking 
>>about mechanism is primarily designed to avoid 
>>prejudging later mechanism documents. However, 
>>if abstract-mech is already settled on a 
>>decision, and if describing it in concepts-uses 
>>is essential background to explain a concept, I 
>>would rather just do that, than dance around in abstract-land.
>>
>>Otherwise readers might imagine we could be 
>>talking about backward ICMP messages or something, and get confused.
>>
>>
>>
>>Bob
>>

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 26 Jun 2011 10:49:55 +0100

Georgios,

The context of those sentences in RFC6077 (which incidentally I 
wrote), was to prove that *if* the network wants to do congestion 
control, claims that it can do this without flow state (e.g. with 
XCP/RCP) overlook the need for inter-domain policing, which will 
require flow state.

The statement about flow state wasn't intended to be taken out of 
context as a general statement that identifying flows is always 
unnecessary. It's only in the context where the network is already 
trying to control congestion at the flow level.

[Anyway, in general (but not in this case) just because a previous 
IRTF document (RFC6077) says something is impossible, doesn't mean a 
later IETF doc cannot standardise something that makes it possible.]

Bob

---

From: "SCHARF, Michael" <[email-masked]>
Date: Sun, 26 Jun 2011 12:28:01 +0200

Georgios, Bob,

I've not followed this discussion. But as another author of RFC 6077 I
want to back Bob's explanation concerning the context. Those sentences
indeed discuss open issues in case that the network performs flow-level
congestion control (XCP, RCP, etc.).

Michael

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bob Briscoe
> Sent: Sunday, June 26, 2011 11:50 AM
> To: Georgios Karagiannis
> Cc: [email-masked]
> The context of those sentences in RFC6077 (which incidentally 
> I wrote), was to prove that *if* the network wants to do 
> congestion control, claims that it can do this without flow 
> state (e.g. with
> XCP/RCP) overlook the need for inter-domain policing, which 
> will require flow state.
> 
> The statement about flow state wasn't intended to be taken 
> out of context as a general statement that identifying flows 
> is always unnecessary. It's only in the context where the 
> network is already trying to control congestion at the flow level.
> 
> [Anyway, in general (but not in this case) just because a 
> previous IRTF document (RFC6077) says something is 
> impossible, doesn't mean a later IETF doc cannot standardise 
> something that makes it possible.]
> 
> 
> Bob
> 
> >identify specific applications or behaviours at the flow 
> level, because 
> >the relevant bulk congestion information is revealed at the network 
> >layer.
> >
> >that network flow state could be  avoided (up to a certain extend) 
> >given the network's per-packet flow  rate instructions that 
> would need 
> >to be compared against variations  in the actual flow rate, which is 
> >Is it possible to explain in the draft how the congestion control 
> >related issues associated with multi-domain scenarios 
> discussed in RFC 
> >6077 are solved/worked out?
> >
> >Best regards,
> >Georgios
> >
> >
> >
> >
> > >    |     |   |                                            
>    |   |     |
> > >    |     |   |                                            
>    |   |     |
> > >    |     |   |             ,-----------.                  
>    |   |     |
> > >    |     |   |             |(Congested)|                  
>    |   |     |

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 26 Jun 2011 15:46:01 +0200

below...

El 26/06/11 11:26, Bob Briscoe escribió:
> Marcelo,
>
> Thanks for this.
>
> There's another option between your options 1 & 2, which I would like 
> to argue for (and perhaps this is what you were really thinking of):
>
> Option 1.5: Reference abstract-mech, but summarise (rather than copy) 
> anything particularly relevant, so that concepts-uses is 
> Reasoning: people don't want to read about a mechanism if they don't 
> know why it might be useful. So we ought to make the 'why' doc the 
> recommended entry-point. Then if that convinces them, they can read 
> the 'how' doc for more details.
>
as co-chair, i think this is perfectly fine is the wg feels that's the 
way to go. I do believe that it is more importnat to move forward than 
the actual approach taken to deal with this though

As an individual, i still believe that simply referencing the abstract 
mechanism is fine. People who don't understand the mechanisms are not 
imho the expected audience of this document. but again, i won't opose 
any appraoch people will preffer.

Regards, marcelo

> I don't like pure option 1 (heavily reference abstract-mech). If 
> information elsewhere is critical to the understanding of a doc, I 
> believe its poor writing style to use a bare reference to the other 
> doc without at least a brief summary of the concept the reader needs.
>
> [Nonetheless, I admit this is going to get unweildy, given 
> concepts-uses has a section on partial deployment. That's very hard to 
> talk about without extensive prior knowledge of the mechanism. But 
> let's at least try it and see.]
>
>
> Bob
>
>
>>> Pls give guidance as wg chairs, so we don't write text you will 
>>> later ask us to remove...
>>>
>>> describe mechanism in conex-concepts-uses. People on the list seem 
>>> to agree that some very high level description of ConEx mechanism is 
>> so, having the use cases separated from the mechanism description is 
>> an artifact from the wh charter creation process.
>> Nevertheless, there are plenty of cases where use cases or 
>> applicability statements are described in different documents than 
>> the actual mechanisms, so, that should be feasible.
>> The wierd thing is our case is that we are supposed to deliver the 
>> use case document before the mechanism description.
>>
>> 1- Since we have a mature mechanism document, we can simply rely on 
>> it to describe the mechanism and assume that reader will read the 
>> abstract mechanism before reading the use case document. We can even 
>> include a normative reference and even if we ship the use case 
>> document to the IESG first, both docs will have to be published 
>> together.
>>
>> 2- We can copy part of the mechanism defined in the mechanism draft 
>> into the use case draft, in order to make it more self contained. The 
>> problem with this is that these two docs needs to be highly 
>> coordinated, in order to avoid contradictions between the docs.
>>
>> 3- We can decide to merge the 2 documents. That would require us to 
>> talk to the iesg and convice them that this is the best approach, but 
>> if the WG feels this is the way to go, we can try it.
>>
>> abstract mechanism and heavily reference it and talk about the 
>> mechanism as described in there. We should ship them both toghter to 
>> the IESG, even if they don't consider the mechanism one for 
>>>> > > >    Hmm... not sure what you mean... In any case, the reader 
>>>> would
>>>> > have
>>>> > >Although the diagram could refer back. Personally, when I come 
>>>> across
>>>> > text
>>>> > > > > I don't think 'complete loop' is useful as people already 
>>>> think
>>>> > of it
>>>> > > > > "...to add a third pass to the feedback loop" says exactly 
>>>> what
>>>> > is
>>>> > > > > happening, doesn't it?
>>>> > > >
>>>> > >saw (which you might want as some sort of nonce for data 
>>>> validity, but
>>>> > isn't
>>>> |-Congestion-Signal-->|--
>>>> > >+
>>>> > > > |
>>>> > > > >>   |         |             .           .                     |
>>>> > |
>>>> > > > |
>>>> > > > > We obviously have two different implicit y axes. You're 
>>>> thinking
>>>> > of
>>>> > > > > time down the page, I'm thinking of layering. I think this 
>>>> shows
>>>> > we
>>>> > > >    Good catch! My Transport Layer Congestion Signal needs 
>>>> "=", not
>>>> > "-".
>>>> > > > "
>>>> > > > "  |     
>>>> +<==|<==Transport=.===Layer===.<==Congestion=Signal=|<==+
>>>> > > > |
>>>> > > >
>>>> > >suggest Bob's diagram is better for the introduction, but I 
>>>> would be
>>>> > keen to
>>>> > >Agree with John - in data packet headers is mechanism. The key 
>>>> point
>>>> > here
>>>> > >That sort of implies packet header, but only if you assume a 
>>>> packet-
>>>> > oriented

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 26 Jun 2011 21:04:11 +0100

Marcelo,

At 14:46 26/06/2011, marcelo bagnulo braun wrote:
>As an individual, i still believe that simply 
>referencing the abstract mechanism is fine. 
>People who don't understand the mechanisms are 
>not imho the expected audience of this document. 
>but again, i won't opose any appraoch people will preffer.

Thanks, that's useful to know.

There does seem to be a mismatch of expectations 
about the audience of concepts-uses here that 
ought to be cleared up. I thought it was intended 
to be the entry-point to ConEx; therefore targeted at newbies.

Bob

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 26 Jun 2011 22:41:15 -0400

On 6/26/2011 4:04 PM, Bob Briscoe wrote:
> There does seem to be a mismatch of expectations about the audience of
> concepts-uses here that ought to be cleared up. I thought it was
> intended to be the entry-point to ConEx; therefore targeted at newbies.
>

I prefer option 1 or 1.5.  I've been thinking of the concepts-uses
document primarily like a ConOps for how conex is envisioned to be
applied, and then the abstract-mech draft as a sort of architecture
description for how the full system can work, with the individual
pieces fleshed out in by the packet structure and TCP documents.

-- 
Wes Eddy
MTI Systems

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Jun 2011 08:05:52 +0200

> intended to be the entry-point to ConEx; therefore targeted at newbies.
mmm, i think scoping the document only to newbies would severely limit 
what you can do. I see it as the description of what you can achieve 
with conex, assuming you understand the conex mechanism. I mean, 
especially in our case that we have an _abstract_ mechanism description, 
i would argue that the reader of the use case should have read the 
abstract mechanism first (but may not have read the actual extensions 
for IPv6 coding or the TCP extensions to support conex)

makes sense?

Regards, marcelo

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Jun 2011 11:14:53 +0100

Marcelo,

At 07:05 27/06/2011, marcelo bagnulo braun wrote:
>>concepts-uses here that ought to be cleared up. 
>>I thought it was intended to be the entry-point 
>>to ConEx; therefore targeted at newbies.
>>
>mmm, i think scoping the document only to 
>newbies would severely limit what you can do. I 
>see it as the description of what you can 
>achieve with conex, assuming you understand the 
>conex mechanism. I mean, especially in our case 
>that we have an _abstract_ mechanism 
>description, i would argue that the reader of 
>the use case should have read the abstract 
>mechanism first (but may not have read the 
>actual extensions for IPv6 coding or the TCP extensions to support conex)
>
>makes sense?

Well, no. Why would anyone read the abstract-mech 
doc without knowing why they wanted to read it?

This conversation is getting a bit disconnected 
from the real docs. So far, we are quite happily 
and very briefly summarising the necessary 
mechanism ideas from abstract-mech into 
concepts-uses. It sounds like you would be happy 
to have references to the mechanism and/or brief 
re-statements of mechanism in concepts-uses. And 
Nandita was already happy with that. So there's no longer a problem.

The question merely arose because Toby was saying 
he had attempted to have some specifics on 
mechanism in concepts-uses before, and he'd been 
asked to make concepts-uses mechanism-independent by the chairs.

Bob

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Jun 2011 16:01:26 +0200

El 27/06/11 12:14, Bob Briscoe escribió:
>
>
> This conversation is getting a bit disconnected from the real docs. So 
> far, we are quite happily and very briefly summarising the necessary 
> mechanism ideas from abstract-mech into concepts-uses. It sounds like 
> you would be happy to have references to the mechanism and/or brief 
> re-statements of mechanism in concepts-uses. And Nandita was already 
> happy with that. So there's no longer a problem.
>
great, i am glad we are making progress

> The question merely arose because Toby was saying he had attempted to 
> have some specifics on mechanism in concepts-uses before, and he'd 
> been asked to make concepts-uses mechanism-independent by the chairs.
>
Let me correct this. The WG input was that this should be removed. 
Please check the minutes from IETF78 proceedings on the use case 
document and the feedback received. The WG chairs we were not stating a 
position on the technical issue, but merely ensuring that the feedback 
received by the WG was reflected in the document.

Regards, marcelo

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 27 Jun 2011 15:54:36 +0100

Sorry to bother the group with this question...

I may have missed the discussion around this, but I was wondering the
opinion around conex marks for TCP flows.

The reason I'm asking is that Conex and ECN are very much tied together
for TCP flows. However, ECN is currently not to be used for non-data
segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] and
[RST]). 

However, for a bidirectional session, wouldn't it be beneficial to also
collect ECN marks (to be fed into Conex) with other types of segment
apart from data segments?

That would - at least for TCP - appear to be simpler than trying to come
up with a new heuristic to detect lost ACKs and use that as source of
Conex marks. In addition, ECN-marked segments are supposed to get
dropped with lower probability too, making features like AckCC more
appealing...

Of course, there may be other transports which currently don't allow ECN
for certain types of packets; Should the rationale for not having ECN on
a global basis be reviewed for Conex enabled stacks?

Thanks,

Richard Scheffenegger

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Jun 2011 11:14:40 -0400

> Sorry to bother the group with this question...

   Turns out, it's an interesting question...

> segments (ie. [SYN], [SYN,ACK] and pure [ACK], as well as [FIN] and

   Certainly, ECN _could_ be used on these; but there's no obvious reason
to -- there's no obvious back-off to be done if congestion is experienced.

> apart from data segments?

   I see no reason that ConEx credit markings couldn't go in a SYN:
indicating an intent to build an initial credit. It does raise some
questions about implementation (which seem premature).

   Thinking it through, this could play a role in DDoS mitigation --
which we've ruled out of the initial presentation.

   Thus it doesn't seem appropriate for -concepts-uses; but perhaps we
might think of hooks when we discuss abstract-mechanism. These non-data
packets are effectively part of the flow; and the ConEx mechanism is a
Layer-3 beast which doesn't care how the sender learns of congestion
experienced.

> Conex marks.

   I'm afraid we're stuck considering lost ACKs anyway, though ECN marks
are a better mechanism...

> In addition, ECN-marked segments are supposed to get dropped with lower
> probability too, making features like AckCC more appealing...

   I'm not sure there's enough consensus yet on lower-drop-probability
for ECN-marked packets. :^(

> a global basis be reviewed for Conex enabled stacks?

   I'm not sure I understand this question.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Jun 2011 16:16:14 +0100

Marcelo,

Thanks - I've gone and read the IETF78 ConEx 
minutes and been reminded of the pressure at that time.

In hindsight I would have pushed back more at the 
time. It is true that the use-cases part of 
concepts-uses should be mechanism independent, 
but it would be overly theoretical to describe 
the concepts (e.g. downstream congestion-volume) 
without using mechanisms as examples.

We need to constantly remind ourselves that concepts-uses has three purposes:
- describe the problem(s)
- concepts
- benefits
- deployment arrangements

(that's four ;)

We haven't even got on to the problems with 
discussing deployment arrangements yet. That will 
be impossible without introducing mechanism, but 
I still think there's a separate role for 
abstract-mech, which has all the precise 
statements about mechanism, while concepts-uses 
can treat all the parts as high-level building blocks.

Bob

At 15:01 27/06/2011, marcelo bagnulo braun wrote:
>>The question merely arose because Toby was 
>>saying he had attempted to have some specifics 
>>on mechanism in concepts-uses before, and he'd 
>Let me correct this. The WG input was that this 
>should be removed. Please check the minutes from 
>IETF78 proceedings on the use case document and 
>the feedback received. The WG chairs we were not 
>stating a position on the technical issue, but 
>merely ensuring that the feedback received by 
>the WG was reflected in the document.
>
>Regards, marcelo
>
>
>>
>>Bob
>>
>>
>>>Regards, marcelo
>>>
>>>
>>>>Bob
>>>>
>>>>
>>>>
>>>>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 27 Jun 2011 16:32:34 +0100

Hi John,

yes, this question is jumping the current discussions on the conex list,
and really belongs in the valley of implementation details :)

My understanding was, that lost *data* segments will provide the input
signal for conex, short of ECN. That is a relatively easy metric to come
by within TCP, whereas lost (+delayed) pure ACKs aren't really accounted
in TCP stacks. Besides, the congestion information conveyed by lost pure
ACKs (no data) is at the wrong end of the connection, and TCP will not
convey that information back to the sender of the ACKs (the receiver of
the data stream at this point in time), unless the TCP ECN mechanism is
used. TCP ECN works bidirectional, so for TCP at least, it appears that
Conex would give a high incentive to have all TCP segments
ECN-capable....

Using RFC3168 ECN marking with TCP however, seems to make things
unnecessary complicated. Whenever the data direction of a TCP flow
changes, the Conex machinery may need to be restarted (because
information learned before may be long outdated). With always ECN
segments, Conex would maintain a good understanding of the network
congestion state, and not need to start from scratch...

My last remark was with respect to DCCP, SCTP, RTTP and other transport
protocols that I'm not really familiar with; they may have similar
limitations on their use of ECN-capable packets as TCP, thus similar
implications. Just to not leave them out completely - but I guess the
Conex/ECN interaction can be discussed with TCP as an example, and
carried to these protocol once the WG comes to a consensus. 

Richard Scheffenegger

> Sent: Montag, 27. Juni 2011 17:15
> To: Scheffenegger, Richard
> Cc: ConEx IETF list
> Subject: Re: [conex] conex marks and tcp
> 
> > for certain types of packets; Should the rationale for not having
ECN
> on

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 27 Jun 2011 17:05:38 +0100

Speaking personally, I think ConEx certainly should apply to initial packets
in any flow (data or not). As I understand it, the main reason RFC3168 ECN
didn't apply to SYN, SYN-ACK and ACK was because the transports would also
be doing hand-shaking for ECN negotiation. Since then there has been work on
activating ECN for SYN-ACK and ACK packets
(http://tools.ietf.org/html/rfc5562), but that is only experimental.

I seem to recall the authors felt there was a good reason not to implement
it on the SYN packet, but I can't for the life of me recall what it was!

Inline...

> Of Scheffenegger, Richard
> Sent: 27 June 2011 16:33
> To: John Leslie
> Cc: ConEx IETF list
> convey that information back to the sender of the ACKs 

OK that is certainly getting into finer details of implementation and
mechanism! One argument goes that every sender (and that includes senders
that are just ACKing received data) should respond to every byte of
congestion they see. But as you say, ACKs aren't ACKed (otherwise you'd get
into an endless cycle)

> (the receiver of

Yep - ConEx certainly should give a strong incentive to enable ECN for both
the end-systems AND the networks - there is already evidence that it would
benefit end-systems, but up till now it has only had marginal benefits for
the network, hence lack of wide deployment (network operators are not
renowned for their altruism)

> congestion state, and not need to start from scratch...

Have you read the earlier documents about re-ECN with TCP?
(http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09) Although
re-ECN uses the IP part of the ECN mechanism it completely replaced the TCP
part

> carried to these protocol once the WG comes to a consensus.

Clearly adding the necessary transport functionality to support ConEx needs
to be done for each transport. I suspect what this WG will end up doing is
giving some guidelines and possibly a canonical TCP example... But that
comes further down the line. First off we have to actually publish a couple
of initial documents!

Toby

> > > Of course, there may be other transports which currently don't
> allow
> > ECN

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 27 Jun 2011 18:08:12 +0200

what you say makes sense to me.

I was just trying to point out the role of the chairs in the process.
In particular i was trying to clarify that it is not that the chairs had 
forced the editors of the document to change the document (hence you 
should verify with them (us) about adding new stuff), it is that the WG 
provided feedback on the document and the chairs merely made sure that 
the feedback was reflected in the doc.

That was the feedback we received then and we enforced it.

Now the document has evolved. Ship the new version and let's see what 
the WG thinks about it. If the WGis happy with it, so will we (at least 
in our role as wg chairs)

El 27/06/11 17:16, Bob Briscoe escribió:
> Marcelo,
>
> Thanks - I've gone and read the IETF78 ConEx minutes and been reminded 
> of the pressure at that time.
>
> In hindsight I would have pushed back more at the time. It is true 
> that the use-cases part of concepts-uses should be mechanism 
> independent, but it would be overly theoretical to describe the 
> concepts (e.g. downstream congestion-volume) without using mechanisms 
> as examples.
>
> We haven't even got on to the problems with discussing deployment 
> arrangements yet. That will be impossible without introducing 
> mechanism, but I still think there's a separate role for 
> abstract-mech, which has all the precise statements about mechanism, 
> while concepts-uses can treat all the parts as high-level building 
> blocks.
>
>
> Bob
>
>>> The question merely arose because Toby was saying he had attempted 
>>> to have some specifics on mechanism in concepts-uses before, and 
>>> he'd been asked to make concepts-uses mechanism-independent by the 
>>> chairs.
>> document and the feedback received. The WG chairs we were not stating 
>> a position on the technical issue, but merely ensuring that the 
>> feedback received by the WG was reflected in the document.
>>
>> Regards, marcelo
>>
>>
>>>
>>> Bob
>>>
>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>>
>>>>>

---

From: Steve Bauer <[email-masked]>
Date: Mon, 27 Jun 2011 12:18:05 -0400

> it on the SYN packet, but I can't for the life of me recall what it was!

See:

http://tools.ietf.org/html/rfc5562#section-4.2

  There are several reasons why an ECN-Capable codepoint must not be
   set in the IP header of the initiating TCP SYN packet.  First, when
   the TCP SYN packet is sent, there are no guarantees that the other
   TCP endpoint (node B in Figure 2) is ECN-Capable, or that it would be
   able to understand and react if the ECN CE codepoint was set by a
   congested router.

   Second, the ECN-Capable codepoint in TCP SYN packets could be misused
   by malicious clients to "improve" the well-known TCP SYN attack.  By
   setting an ECN-Capable codepoint in TCP SYN packets, a malicious host
   might be able to inject a large number of TCP SYN packets through a
   potentially congested ECN-enabled router, congesting it even further.

   For both these reasons, we continue the restriction that the TCP SYN
   packet must not have the ECN-Capable codepoint in the IP header set.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 27 Jun 2011 12:29:41 -0400

> it on the SYN packet, but I can't for the life of me recall what it was!

The reasons why it's not proposed for the SYN are laid out in Section
4.2 of RFC 5562.  Basically, there's no guarantee that the other side
is ECN-capable, and there may be some potential for misuse in a
variation of a SYN flood attack (this could be sketchy, the example
given in 5562 doesn't seem very strong to me).

For ECN marks in ACK segments, note that RFC 5690 examines a lot of
issues for using these for ACK congestion control, which should have
similar applicability to using them for conex.

-- 
Wes Eddy
MTI Systems

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 27 Jun 2011 17:51:47 +0100

Hi Tony,

Not to have ECN on [SYN] was to mitigate DDoS attacks apparently. OTOH,
DDoS packets can not be expected to not bend some rules. If ECN-marked
packets are seen as getting delivered with higher likelihood, a DDoS
would probably use that. And I don't know a stack that would throw away
ECN-marked SYNs (but a firewall rule would be easy to set up though,
while under attack).

Yes, I read Bob's drafts; for the most part, the exact semantics of the
ECN signaling in TCP are changed, but the Re-ECN draft was a little bit
ambiguous when it comes to pure ACKs (or other non-SYN, non-data
segments). Effectively, the "which packets carry ECN" aligns with
RFC3168, with the exception of all SYNs...

The text effectively allows ECN for [SYN] and [SYN, ACK], but always
talks about "data" segments in section 6 ff.

Table 6 then shows "RECT" set for pure ACKs,  too (line 8 and 11). 

In section 6.1.5 however, the text forbade ECN marking for
retransmissions, and non-data segments (pure ACKs, window probes, FIN,
RST with no data)... This contradicts the example in table 6... A
missing thorough security analysis being quoted as the reasoning, but
the stated goal then was also, to have all TCP segments marked re-ecn
(=ECN) capable.

In effect, reECN seems to align with an approach to allow ECN on *every*
TCP segment. From my point of view, with Conex that would also be the
natural thing to do. Just wanted to clarify this, so that it doesn't get
lost when the interaction with TCP is to be specified for a canonical
TCP implementation. The mentioned security analysis will need to be done
prior to defining that Conex/TCP interaction though.

Richard Scheffenegger

> From: Toby Moncaster [mailto:[email-masked]]
> Sent: Montag, 27. Juni 2011 18:06
> To: Scheffenegger, Richard; 'John Leslie'
> Cc: 'ConEx IETF list'
> Subject: RE: [conex] conex marks and tcp
> 
> congestion they see. But as you say, ACKs aren't ACKed (otherwise
you'd
> get
> re-ECN uses the IP part of the ECN mechanism it completely replaced
the
> TCP
> to be done for each transport. I suspect what this WG will end up
doing
> > > > However, for a bidirectional session, wouldn't it be beneficial
> to
> > > also
> > >    Thinking it through, this could play a role in DDoS mitigation
-
> -
> > >    Thus it doesn't seem appropriate for -concepts-uses; but
perhaps
> > > packets are effectively part of the flow; and the ConEx mechanism
> is
> > a
> > > > That would - at least for TCP - appear to be simpler than trying
> to
> > > come
> > > > up with a new heuristic to detect lost ACKs and use that as
> source
> > of
> > > > Conex marks.
> > >
> > > > In addition, ECN-marked segments are supposed to get dropped
with
> > > lower

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 28 Jun 2011 07:00:27 +0200

Hi

ECN+ (as it is also called) is discussed in this paper
http://www.cs.northwestern.edu/~akuzma/doc/ecn.pdf
ECN+ was recently discussed in the buferbloat list and there was a mention of some issues with it, no details though.
https://lists.bufferbloat.net/pipermail/bloat/2011-March/000365.html

/Ingemar

> From: Scheffenegger, Richard [mailto:[email-masked]] 
> Sent: den 27 juni 2011 18:52
> To: Toby Moncaster; John Leslie
> Cc: ConEx IETF list
> Not to have ECN on [SYN] was to mitigate DDoS attacks 
> apparently. OTOH, DDoS packets can not be expected to not 
> bend some rules. If ECN-marked packets are seen as getting 
> delivered with higher likelihood, a DDoS would probably use 
> that. And I don't know a stack that would throw away 
> ECN-marked SYNs (but a firewall rule would be easy to set up 
> though, while under attack).
> 
> 
> Yes, I read Bob's drafts; for the most part, the exact 
> semantics of the ECN signaling in TCP are changed, but the 
> Re-ECN draft was a little bit ambiguous when it comes to pure 
> ACKs (or other non-SYN, non-data segments). Effectively, the 
> "which packets carry ECN" aligns with RFC3168, with the 
> exception of all SYNs...
> 
> 
> The text effectively allows ECN for [SYN] and [SYN, ACK], but 
> always talks about "data" segments in section 6 ff.
> 
> retransmissions, and non-data segments (pure ACKs, window 
> probes, FIN, RST with no data)... This contradicts the 
> example in table 6... A missing thorough security analysis 
> being quoted as the reasoning, but the stated goal then was 
> also, to have all TCP segments marked re-ecn
> (=ECN) capable.
> 
> 
> 
> In effect, reECN seems to align with an approach to allow ECN 
> on *every* TCP segment. From my point of view, with Conex 
> that would also be the natural thing to do. Just wanted to 
> clarify this, so that it doesn't get lost when the 
> interaction with TCP is to be specified for a canonical TCP 
> implementation. The mentioned security analysis will need to 
> be done prior to defining that Conex/TCP interaction though.
> 
> Richard Scheffenegger
> 
> 
> 
> 
> > Speaking personally, I think ConEx certainly should apply 
> to initial 
> > packets in any flow (data or not). As I understand it, the 
> main reason 
> > RFC3168 ECN didn't apply to SYN, SYN-ACK and ACK was because the 
> > transports would also be doing hand-shaking for ECN 
> negotiation. Since 
> > then there has been work on activating ECN for SYN-ACK and 
> ACK packets 
> > I seem to recall the authors felt there was a good reason not to 
> > implement it on the SYN packet, but I can't for the life of 
> me recall 
> > what it was!
> > 
> > Inline...
> > 
> > > yes, this question is jumping the current discussions on 
> the conex 
> > > list, and really belongs in the valley of implementation 
> details :)
> > >
> > > signal for conex, short of ECN. That is a relatively easy 
> metric to 
> > > come by within TCP, whereas lost (+delayed) pure ACKs 
> aren't really 
> > > accounted in TCP stacks. Besides, the congestion information 
> > > conveyed by lost pure ACKs (no data) is at the wrong end of the 
> > > connection, and TCP will
> > not
> > mechanism! One argument goes that every sender (and that includes 
> > senders that are just ACKing received data) should respond to every 
> > byte of congestion they see. But as you say, ACKs aren't ACKed 
> > (otherwise
> you'd
> > get
> > into an endless cycle)
> > 
> > > (the receiver of
> > > the data stream at this point in time), unless the TCP 
> ECN mechanism
> > is
> > Yep - ConEx certainly should give a strong incentive to 
> enable ECN for 
> > both the end-systems AND the networks - there is already 
> evidence that 
> > it would benefit end-systems, but up till now it has only 
> had marginal 
> > benefits for the network, hence lack of wide deployment (network 
> > operators are not renowned for their altruism)
> > 
> > >
> > Clearly adding the necessary transport functionality to 
> support ConEx 
> > needs to be done for each transport. I suspect what this WG 
> will end 
> > up
> doing
> > is
> > comes further down the line. First off we have to actually 
> publish a 
> > couple of initial documents!
> > 
> > Toby
> > 
> > 
> > >
> > > Richard Scheffenegger
> > >
> > >
> > >
> > > > > for TCP flows. However, ECN is currently not to be 
> used for non-
> > > data
> > > > > segments (ie. [SYN], [SYN,ACK] and pure [ACK], as 
> well as [FIN]
> > and
> > > > > [RST]).
> > > >
> > > >    Certainly, ECN _could_ be used on these; but there's 
> no obvious 
> > > > reason to -- there's no obvious back-off to be done if 
> congestion 
> > > > is experienced.
> > > >
> > > >    I'm afraid we're stuck considering lost ACKs anyway, 
> though ECN 
> > > > marks are a better mechanism...
> > > >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 01 Jul 2011 06:39:22 +0000

Hi Bob, Hi Michael,

After discussing this issue with Dimitri (also a co-author of RFC 6077) I
understood that the problem related to the need of network flow state 
in multi-domain scenarios, during congestion control, comes from the
"non-cooperative" behavior and untrustable nature of the information:
whether congestion control information exchanges are "implicit" or
"explicit" and "rate-based" vs "indication/marks" it doesn't
actually matter: enforcement at the level were the information is
referring to/referrent (can be per flow or per aggregate or other) will
be performed at domain boundaries. Meaning that domain edges do never
trigger any action from "external" information that is not verifiable
(BGP is the only exception but we would speak at the routing level here).

What RFC 6077 actually mentions wrt to scalability is that if signaling
is performed on a per flow state basis it will in addition impact
scaling of domain edges.

Best regards,
Georgios