Re: [re-ECN] CONEX problem statement

[<[e-mail]>]

To supplement the charter problem statement below, here is a proposal
for CONEX output. We will firm up Milestones when there is some
agreement on the list of Output.

Please send comments. Sorry for the delay.
Thanks
Phil & Leslie

== CONEX output ==
1. An applicability statement that consists of
A. the functionality /capability that is expected to be provided by the
conex mechanism itself, including its architectural features,
limitations and assumptions it makes about networks and end systems 
B. deployment analysis - how the conex mechanism can be deployed in
networks (non vs ECN vs [perhaps] Conex routers) and end systems 
C. security analysis - threats from falsifying or blanking conex info

The purpose is 
[1] to detail the key functional and non-functional considerations that
guide the work on the mechanism's design 
[2] to allow exploration of use cases to begin before work on the
mechanism is complete

2. Specification of IP (v4 & v6) packet structure to carry conex
information (header bits, interpretation)

3. Transport-related Best practices and specifications:
[1] for the transport of congestion information from the destination to
the sender, 
[2] for ensuring the trustworthiness of the conex information
Note: capability negotiation is out of scope, except to the extent that
a Conex sender should either be able to work with a legacy destination
or be able to fall-back to non-Conex operation. 

4. Use cases -- possible uses of conex information to reduce congestion
and/or increase the accountability for it. The main purpose is to
encourage experiments that use conex information and to describe their
results; it is not to delineate all potential uses cases, not to provide
a full architectural /deployment /security analysis of use cases. Future
work may include specifications to implement one or more use cases. 

The output is Informational and Experimental, apart from #2 which is
tentatively slated as Standards track.

== Milestones include == 
Milestone: spec of TCP modification to achieve 3[1]. Note, other
transport-related issues eg capability negotiation is out of scope of
this milestone.

Milestone: spec of a mechanism to achieve 3[2]. Note, the purpose is to
ensure the viable *use* of congestion exposure, so the spec should not
be targeted at a specific use case.

Note: these 2 spec Milestones don't have to wait for the Transport best
practices doc; doing the specs should help with it.
 
More Milestones - to be decided  
----

> -----Original Message-----
> From: Leslie Daigle [mailto:[e-mail]]
> Sent: 20 November 2009 22:55
> To: [e-mail]
> Cc: Eardley,PL,Philip,DEE1 R
> Subject: CONEX problem statement
> 
> 
>  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]
> -------------------------------------------------------------------