Re: [re-ECN] CONEX problem statement

[<[e-mail]>]

> -----Original Message-----
> From: Moncaster,T,Toby,DEE1 R
> Sent: 02 December 2009 17:23
> To: Eardley,PL,Philip,DEE1 R; [e-mail]; [e-mail]
> Subject: RE: [re-ECN] CONEX problem statement
> 
> 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?

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.

> 
> 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...

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

> 
> 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