[re-ECN] CONEX problem statement

[Leslie Daigle <[e-mail]>]

 From the BoF, this is the text of the proposed charter problem 
statement for which there was support:

"The purpose of the CONEX working group is to develop a mechanism to 
allow senders to inform the network of the level of congestion they 
expect their packets to encounter. This information is currently only 
visible at the transport layer. With the output of CONEX, it will be 
possible to provide sufficient information in each IP datagram so that 
any node in the network can see the expected rest-of-path congestion. 
Once any node can see the impact it causes (and suffers) by sending or 
forwarding packets, it will be possible to hold senders and whole 
networks accountable for the congestion they cause downstream. Tools 
that exploit the CONEX output could be used for mitigating distributed 
denial of service (DDoS); simplifying differentiation of quality of 
service (QoS); policing compliance to congestion control; and so on.
"

In the interest of making progress, I'd like to leave this on the table 
as the set problem statement for now, and get back to focusing on the 
next section -- the planned output of the proposed WG.

Phil has been drafting some thoughts, and he & I will be back with some 
proposed text for that, next week, but I'd like to flag that I've heard:

. for education/illustration/general success, we need applicability 
statement(s) and/or congestion exposure definition.

. the chief specification for IP packets only (not transport)

. we do need a transport specification -- as these illustrate how to use 
the IP packet information, but are independent of IP packet 
specification.  There may be multiple.  We'll have one listed in the 
milestones section.

. the detail work will be in determining what needs to be documented to 
ensure viable *use* of congestion exposure, without muddling crisp 
specifications or bending them to specific cases.

. to demonstrate viability of the overall approach, we need to have some 
expression of deployability -- can this (at the IP layer, or transport) 
be useful if it is not supported globally, out of the box? (And there 
are "yes" answers -- the point here is that they will need to be 
documented).


Leslie.


-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------