Subject: Re: [re-ECN] CONEX problem statement

From: <[email-masked]>
Date: Wed, 2 Dec 2009 16:36:31 -0000

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:[email-masked]]
> Sent: 20 November 2009 22:55
> To: [email-masked]
> 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
> [email-masked]
> -------------------------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 2 Dec 2009 17:23:22 -0000

This seems pretty reasonable to me. I would think at least some of the
existing problem statement draft can be re-used for the applicability
statement along with some of the non-protocol specific text in the two
re-ECN drafts.

For capability negotiation I assume you mean the specific mechanism is
out of scope, not the need for some form of mechanism?

In 4. Use Cases did "... cases, not to..." mean "... cases, nor to..."?

Should we specify some common structure or similar for the use cases? In
other words what info do we need in the use case documents to make them
useful. It is easy to think up use cases and just say "it can be used
for this" harder to check that they are sensible unless we require a
certain rigour in how they are presented... 

Toby

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 02 December 2009 16:37
> To: [email-masked]; [email-masked]
> Subject: Re: [re-ECN] CONEX problem statement
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 2 Dec 2009 20:57:37 +0100

Hi,

> C. security analysis - threats from falsifying or blanking conex info
I'm not sure if you can specify architectural features without having an 
concret mechanism. Regarding re-ECN this would be droper and policer, right? 
There might be different solutions possible... 

> or be able to fall-back to non-Conex operation.
I would say:  [1] requirements for the transport of congestion information....

BR,
Mirja

---

From: <[email-masked]>
Date: Thu, 3 Dec 2009 09:32:26 -0000

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Mirja Kuehlewind
> Sent: 02 December 2009 19:58
> To: [email-masked]

Was thinking that 1C is analysing the threats, but the actual security
mechanism work (best practices & spec) is done under Item 3[2] (& yes,
this would be re-ecn's dropper or whatever alternative is developed).
the scope of 1A was about the scope of the basic mechanism to 
allow senders to inform the network of the level of congestion they 
expect their packets to encounter.

> I would say:  [1] requirements for the transport of congestion

the intention of 3[1] was to describe best practices for the transport,
whether it's implemented in tcp, rtcp or whatever, and secondly to
specify this in tcp. I guess you could call the former requirements
(depending how interpret the term!), but not the latter.

---

From: <[email-masked]>
Date: Thu, 3 Dec 2009 09:40:34 -0000

> From: Moncaster,T,Toby,DEE1 R
> Sent: 02 December 2009 17:23
> To: Eardley,PL,Philip,DEE1 R; [email-masked]; [email-masked]
> Subject: RE: [re-ECN] CONEX problem statement
> 
re-
> ECN drafts.
out
> of scope, not the need for some form of mechanism?

Yes, it means: it's out of scope (at least for the initial set of work).

> In 4. Use Cases did "... cases, not to..." mean "... cases, nor
to..."?

you're right.

> useful. It is easy to think up use cases and just say "it can be used
for
> this" harder to check that they are sensible unless we require a
certain
> rigour in how they are presented...

a common structure can be decided later by the WG - it seems a good idea
to me. The wording below is supposed to convey: we're not trying to
exhaustively collect all possible use cases - better would be to hear
results from some actual experiments of a few use cases. 

phil

> > > Once any node can see the impact it causes (and suffers) by
sending
> > or