Re: [re-ECN] Complete draft Charter for proposed CONEX WG

[<[e-mail]>]

> -----Original Message-----
> From: Eardley,PL,Philip,DEE1 R
> Sent: 10 December 2009 10:41
> To: Moncaster,T,Toby,DEE1 R; '[e-mail]'
> Subject: RE: [re-ECN] Complete draft Charter for proposed CONEX WG
> 
> Thanks toby & john
> > > ---
> > >
> > > The purpose of the CONEX working group is to develop a mechanism
to
> >
> > The CONEX working group will develop mechanisms to
> 
> "mechanisms" might imply that we going to develop several different
> ways of doing this.
> So I prefer keeping as "a mechanism" (albeit one with several parts -
> which I think was your point)
> 
> >
> > > 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.
> >
> 
> I think everyone so far is ok with mirja's suggestion to add "in the
> end systems", please shout if I mis-interpreted.

I'm OK with it. Arguably it should perhaps be "at the transport layer
and above"

> 
> > Although I agree with Mirja's comment, an argument that could
> > be made to say the information is visible in the network if
> > you use DPI equipment... However I think highlighting that
> > only the end-systems are DESIGNED to see the info is a good thing...
> >
> > > 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.
> >
> > I think I would prefer to say "The main output of CONEX will
> > be a protocol that allows each IP datagram to carry
> > sufficient information to allow any node in the network to
> > see the whole path congestion." I make the subtle distinction
> > between rest of path and whole path so that we leave the door
> > open for Matt Mathis's mark on drop suggestion...
> 
> Please can you remind me what Matt's suggestion is.
> At the moment, prefer to leave as "rest-of-path congestion" (knowing
> one implies knowing the other, and rest-of-path emphasises the new
info
> useful for a router, as john says)

Matt is suggesting we react to drops by inserting marks in the forward
path. That will give packets that carry whole path congestion
information but there will be no way to measure rest of path info from
IP header... I just want to try and make sure we don't close the door on
that suggestion as it is a good potential deployment scenario. The only
possible way round it is to claim that to the sender whole path and rest
of path are identical... But as you worded it Matt's approach wouldn't
be CONEX

> 
> >
> > > 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.
> > > Intended output of the WG: 1. An applicability statement
> > that consists
> > > of
> >
> > Don't like "consists of" would prefer something like
> > "explains" or "describes"
> 
> Ok
> 
> >
> > > 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
> >
> > Including analysis of the impact of full vs partial
> > deployment (or something like this - highlight that what
> > matters is how we get to a system that is useful)
> 
> This raises an interesting question. There are several deployment
> issues:
> * the functionality of the routers (non, ECN, maybe CONEX, maybe a
mix)
> * the functionality of the end systems (is the destination non, ECN,
> CONEX?)
> * the functionality of the network (specifically, this about the
> enforcement of trustworthiness of conex info)
> 
> The 3rd one seems to me a big issue, & one that first requires work on
> the mechanism in 3B. So I see network-by-network partial deployment as
> a use case, potentially to be explored under item 4.
> 
> "Output Item 1" (APPlicability) is intended to be early work "to
detail
> the key functional and non-functional considerations that guide the
> work on the mechanism's design".
> I'm not convinced that network-by-network deployment analysis falls
> into this category.
> 
> But maybe just my perception!

One of the big questions we could try and answer is what happens if each
element moves first, and the combinations. Who gets the benefit most
quickly. Do the benefits come on the correct timescales (e.g. an end
user would want to see an immediate benefit whereas a network operator
may be prepared to invest time and money if it gives a significant
saving in the long term). We also need to look at what happens if people
don't do it (what if network X refuses to upgrade, does it matter, what
is impact on X and what on its neighbours? What if a major OS refuses to
install this? What are the impacts on their customers. Etc)


> 
> >
> > > C. security analysis - threats from falsifying or blanking
> > CONEX info
> >
> > Think I would just all that a threat analysis and I think
> > there is a good chance it could exist as a separate document...
> >
> > > 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:
> >
> > Add the word "covering" after specifications...
> 
> Ok
> 
> >
> > > A. for the transport of congestion information from the
> > destination to
> > > the sender,
> >
> > For the timely transport ?
> >
> > > B. 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.
> >
> > Somewhere in work items 2 or 3 we need to specifically refer
> > to a need to mitigate those threats identified in the threat
> > analysis...
> 
> Ok
> 
> >
> >
> > >
> > > 4. Use cases -- possible uses of CONEX information to reduce
> > > congestion and/or increase the accountability for it.
> >
> > This first sentence seems to pre-suppose which use cases are
> > of interest... Perhaps change it to "possible uses of CONEX
> > information which include controlling or reducing congestion
> > and increasing accountability for congestion."
> 
> Ok. Widening the text allows things like simply monitoring the info,
in
> order to do some off-line network planning perhaps
> 
> >
> > > 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, nor to
> > > provide a full architectural/deployment/security analysis of use
> > > cases. Future work may include specifications to implement
> > one or more
> > > use cases.
> >
> > Highlight that we expect there to be a number of use case
> > documents (or a number of sections within a master use case
> document).
> 
> Think we can leave this to the WG to decide.
> 
> >
> > > The output is Informational and Experimental, apart from #2
> > which is
> > > tentatively slated as Standards track.
> > >
> > > Milestones
> > > Feb 2010 Internet-Draft functionality statement (Output
> > item 1A) Mar
> > > 2010 Internet-Draft applicability statement (Output item
> > 1A, B, C) Mar
> > > 2010 Internet-Draft(s) for CONEX IPv4 & IPv6 specifications
(Output
> > > item 2) May 2010 Internet-Draft use cases (Ouput item 4)
> > > Jun 2010 First WG draft CONEX IPv4 specification
> > > Jun 2010 First WG draft CONEX IPv6 specification
> > > Jun 2010 Draft transport-related best practices
> > > Jun 2010 Proposals (individual I-Ds) for TCP modification
> > (Ouput item
> > > 3A)
> > > Jun 2010 Proposals (individual I-Ds) for mechanism to ensure
> > > trustworthiness of CONEX information (Ouput item 3B)
> > > Sep 2010 Complete applicability statement (sent to IESG)
> > > Nov 2010 CONEX IPv4 specification to WGLC
> > > Nov 2010 CONEX IPv6 specification to WGLC
> > > Jan 2011 Complete IPv4 specification (sent to IESG)
> > > Jan 2011 Complete IPv6 specification (sent to IESG)
> > > Mar 2011 Spec of TCP modification to WGLC
> > > Mar 2011 Spec of mechanism to ensure trustworthiness to WGLC
> > > Mar 2011 Transport-related best practices to WGLC
> > > Mar 2011 Use cases to WGLC
> > > May 2011 Complete remaining docs (sent to IESG)
> > > Jun 2011 Close or re-charter
> >
> > My word that's an exhaustive list of milestones! For
> > simplicity can we also break out the list of intended
> > publication dates for the final outputs? My personal instinct
> > is that we should be able to publish the applicability
> > statement in July or at least WGLC it. Also sometime round
> > November 2010 we need to actually select which individual IDs
> > we are progressing for TCP and trustworthiness...
> 
> Thnks, we'll have a think whether there's a better way to list them.

One suggestion: Use an approach like this:

May 2010   IND  Internet-Draft use cases (Ouput item 4) 
Jun 2010   WGD  First WG draft CONEX IPv4 specification 
Sep 2010   INF  Complete applicability statement (sent to IESG) 

Where you add a column for IND (individual draft), WGD (working group
draft), WLC (WG LC), INF (informational RFC), EXP (experimental RFC) and
STD (standards RFC). 

That allows people to pick out the key milestones. Or even simpler use *
to highlight those milestones that are draft to IESG for publication...

> 
> >
> > Toby
> >