Re: [re-ECN] CONEX problem statement

[<[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: 02 December 2009 16:37
> To: [e-mail]; [e-mail]
> Subject: Re: [re-ECN] CONEX problem statement
> 
> 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]
> > -------------------------------------------------------------------
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn