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

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 7 Jan 2010 15:32:21 +0100

WARNING: contains banned part

Subject: Re: Complete draft Charter for proposed CONEX WG
From: "Ingemar Johansson S" <[email-masked]>
To: <[email-masked]>
Date: Thu, 7 Jan 2010 15:32:21 +0100

Hi

If I get things correct idea is to create one IP doc and a number of transport docs (TCP, RTP/UDP....), this sounds OK. 

My feeling is that the IP doc needs to set some requirements on the feedback/reinsertion done by the transport. The reason I see is that no requirements at all on this level will make it difficult to design and tune the incentive droppers and congestion rate policers. 

The use of bit 48 in the IPv4 header is probably one thing that will raise the noise level on the list. The IP doc will here need to specify how this can be used safely (if posssible)    

PS. Is it possible that you could post a refreshed version of the draft charter on this list as it is a bit difficult to follow the discussion (esp after being away after being out of office for a longer period).

Regards
Ingemar

----------------------------------------------------------------------

Message: 1
Date: Tue, 05 Jan 2010 13:48:38 +0000
From: Bob Briscoe <[email-masked]>
Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG
To: <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Phil,

I'm happy with both responses.

one outstanding issue inline...

At 11:44 05/01/2010, [email-masked] wrote:
> >
> > [BB]: A radically new approach is unlikely to be successful if people
> > can't get an intuitive grasp of it. E.g. HIP would have been unlikely
> > to get anywhere without RFC4423. We know ConEx hasn't been easy for
> > newcomers to grasp, so we shouldn't fudge this issue.
> >
> > I was thinking of a framework/architecture doc. Here's an idea...
> >
> > Let's assume the use-cases item is >1 doc, rather than a single
> > monolithic doc for all use-cases, ie. we encourage different people
> > to document their own use-cases.
> >
> > If so, then someone could attempt to write a more generic use-cases
> > doc that describes building blocks that can be used to build the
> > other use-cases. This could become a README-FIRST if written well, as
> > it's difficult to introduce ConEx without describing how it
> > might be used.
>
>An "intuitive guide" would be possible, although adding another doc is
>more work. I wonder if the applicability statement can be tweaked for
>this purpose. We could add another "purpose":
>[3] to provide an intuitive explanation of the new concepts in CONEX
>
>So that it reads as follows:-
>
>1. An applicability statement that describes:
>
>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. a deployment analysis - how the CONEX mechanism can be deployed in
>networks (non vs ECN vs perhaps CONEX routers) and end systems
>
>C. a threat analysis - threats from falsifying or blanking CONEX info

The milestones have the applicability statement going to the IESG
before the ConEx protocol is specified, so...

B. I'm not convinced we will be able to write a deployment analysis
of a protocol as yet to be defined - we can surely only write
requirements at that stage.
C. And it's certainly not possible to write a meaningful threat
analysis of something that hasn't yet been specified.

These problems would be solved by altering the chartering text as follows:
s/deployment analysis/
  /deployability goals/
s/threat analysis - threats from.../
  /security goals - addressing threats from.../

Then after the protocol has been specified:
- deployment analysis could be in "4. use-case(s)"
- full threat analysis could be in "3B trust mechanisms"

Bob

>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
>
>[3] to provide an intuitive explanation of the new concepts in CONEX
>
> >
>
> > Where do you imagine we should put best practice for the sending
> > transport to set its expectation of congestion?
> > - The above EXP for e2e transport,
> > - or within the ConEx-IP doc (if so, which one? v4 or v6)?
> > It would seem to fit better in the e2e transport one, then the spec
> > for TCP could provide an example of the complete best practice.
>
>Yes, same as you - I'd imagined it would be in the e2e transport doc.
>The IP doc defines packet the structure to carry CONEX information  - ie
>what the codepoints are and what they mean. "what they mean" of course
>influences what the sending transport should do, but the advice for the
>sending transport would be in the transport doc [things like "send, as
>soon as possible, a Black codepoint for every loss or mark notified by
>the receiver". or whatever!]
>
>Thanks
>phil
>
> > IOW, this proposal assumes the IP doc would not need to describe
> > semantics of *when* the transport sets the codepoints. Instead it
> > would focus on just the wire protocol - what the codepoints mean, how
> > they are encoded, tunnel processing, router forwarding behaviour,
> > errors & management etc.
> >
> > Altho I'm not implying re-ECN is any more than a candidate, it would
> > be a useful exercise to go through the contents of the re-ECN
> > protocol spec <draft-briscoe-tsvwg-re-ecn-tcp-08> and check where you
> > assume the different sections will end up. I've just done that, which
> > is why I keep bringing up awkward questions.
> >

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

------------------------------

_______________________________________________
re-ECN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn

End of re-ECN Digest, Vol 11, Issue 2
*************************************

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 07 Jan 2010 10:42:46 -0400

Hi,

For the (public) record, here's the most recent version of the charter. 
  Phil sent it along to Lars for his consideration, yesterday.  I think 
we'll wait to hear feedback from him before doing more serious mods on 
the charter -- I think (hope!) we're really close, and can be focusing 
on getting the work items moving.

Congestion Exposure (CONEX) WG

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 in the end systems. 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.

The WG will work on the following topics (see later for the list of 
documents):

B. deployability goals - how the CONEX mechanism can be deployed in 
networks (non vs ECN vs perhaps CONEX routers) and end systems

C. security goals - addressing threats from falsifying or blanking CONEX 
info

The purpose is

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

3. Transport-related Best practices and specifications:

A. for the timely transport of congestion information from the 
destination to the sender,

B. for ensuring the trustworthiness of the CONEX information (to 
mitigate the threats identified in 1C)

4. Use cases -- possible uses of CONEX information, which include 
controlling or reducing congestion and increasing accountability for 
congestion. 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.

The output is Informational and Experimental, apart from #2 which is 
tentatively slated as Standards track. Depending on the bits that are 
proposed to be used in the IP header and their semantics (eg Bit 48 in 
IPv4, ECN nonce), there may need to be further STD or INFO documents to 
reassign the bits from their current definition(s) (which would be 
subject to appropriate IESG and IETF review as necessary).

Milestones & List of documents to be produced:

== Related to Output Item 1 ==

Feb 2010 Internet-Draft functionality statement (Output item 1A)

Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C)

July 2010 Applicability statement to WGLC

Sep 2010 Applicability statement sent to IESG (INFO)

== Related to Output Item 2 ==

Mar 2010 Proposals (individual I-Ds) for CONEX IPv4 & IPv6 specifications

Jun 2010 First WG draft CONEX IPv4 specification

Jun 2010 First WG draft CONEX IPv6 specification

Nov 2010 CONEX IPv4 specification to WGLC

Nov 2010 CONEX IPv6 specification to WGLC

Jan 2011 IPv4 specification sent to IESG (STD)

Jan 2011 IPv6 specification sent to IESG (STD)

== Related to Output Item 3 ==

Jun 2010 Draft transport-related best practices

Jun 2010 Proposals (individual I-Ds) for TCP modification

Jun 2010 Proposals (individual I-Ds) for mechanism to ensure 
trustworthiness of CONEX information

Mar 2011 Transport-related Best practices for ensuring the 
trustworthiness of the CONEX information, including Spec of one 
mechanism to WGLC (EXP)

Mar 2011 Transport-related Best practices for the transport of 
congestion information from the destination to the sender, including 
Spec of TCP modification to WGLC (EXP)

May 2011 Both transport-related docs sent to IESG

== Related to Output Item 4 ==

May 2010 Internet-Draft use cases

Mar 2011 Use cases to WGLC

May 2011 Use cases sent to IESG (INFO)

==
Jun 2011 Close or re-charter

Leslie.

Ingemar Johansson S wrote:
> ------------------------------------------------------------------------
> 
> 
> Subject: Re: Complete draft Charter for proposed CONEX WG From: 
> "Ingemar Johansson S" <[email-masked]> Date: Thu, 7
> Jan 2010 15:32:21 +0100 To: <[email-masked]>
> 
> To: <[email-masked]>
> 
> 
> 
> Hi
> 
> If I get things correct idea is to create one IP doc and a number of
> transport docs (TCP, RTP/UDP....), this sounds OK.
> 
> My feeling is that the IP doc needs to set some requirements on the
> feedback/reinsertion done by the transport. The reason I see is that
> no requirements at all on this level will make it difficult to design
> and tune the incentive droppers and congestion rate policers.
> 
> The use of bit 48 in the IPv4 header is probably one thing that will
> raise the noise level on the list. The IP doc will here need to
> specify how this can be used safely (if posssible)
> 
> PS. Is it possible that you could post a refreshed version of the
> draft charter on this list as it is a bit difficult to follow the
> discussion (esp after being away after being out of office for a
> longer period).
> 
> Regards Ingemar
> 
> 
> 
> Message: 1 Date: Tue, 05 Jan 2010 13:48:38 +0000 From: Bob Briscoe
> <[email-masked]> Subject: Re: [re-ECN] Complete draft
> Charter for proposed CONEX WG To: <[email-masked]> Cc:
> [email-masked] Message-ID:
> <[email-masked]> Content-Type:
> text/plain; charset="us-ascii"; format=flowed
> 
> Phil,
> 
>>> [BB]: A radically new approach is unlikely to be successful if
>>> people can't get an intuitive grasp of it. E.g. HIP would have
>>> been unlikely to get anywhere without RFC4423. We know ConEx
>>> hasn't been easy for newcomers to grasp, so we shouldn't fudge
>>> this issue.
>>> 
>>> monolithic doc for all use-cases, ie. we encourage different
>>> people to document their own use-cases.
>>> 
>>> If so, then someone could attempt to write a more generic
>>> use-cases doc that describes building blocks that can be used to
>>> build the other use-cases. This could become a README-FIRST if
>>> written well, as it's difficult to introduce ConEx without
>>> describing how it might be used.
>> An "intuitive guide" would be possible, although adding another doc
>> is more work. I wonder if the applicability statement can be
>> tweaked for this purpose. We could add another "purpose": [3] to
>> provide an intuitive explanation of the new concepts in CONEX
>> 
>> 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. a deployment analysis - how the CONEX mechanism can be deployed
>> in networks (non vs ECN vs perhaps CONEX routers) and end systems
>> 
> requirements at that stage. C. And it's certainly not possible to
> write a meaningful threat analysis of something that hasn't yet been
> specified.
> 
> These problems would be solved by altering the chartering text as
> follows: s/deployment analysis/ /deployability goals/ s/threat
> analysis - threats from.../ /security goals - addressing threats
> from.../
> 
> Then after the protocol has been specified: - deployment analysis
> could be in "4. use-case(s)" - full threat analysis could be in "3B
> trust mechanisms"
> 
> 
> Bob
> 
> 
> 
>> The purpose is [1] to detail the key functional and non-functional
>> considerations that guide the work on the mechanism's design
>> 
>>> transport to set its expectation of congestion? - The above EXP
>>> for e2e transport, - or within the ConEx-IP doc (if so, which
>>> one? v4 or v6)? It would seem to fit better in the e2e transport
>>> one, then the spec for TCP could provide an example of the
>>> complete best practice.
>> Yes, same as you - I'd imagined it would be in the e2e transport
>> doc. The IP doc defines packet the structure to carry CONEX
>> information  - ie what the codepoints are and what they mean. "what
>> they mean" of course influences what the sending transport should
>> do, but the advice for the sending transport would be in the
>> transport doc [things like "send, as soon as possible, a Black
>> codepoint for every loss or mark notified by the receiver". or
>> whatever!]
>> 
>> Thanks phil
>> 
>>>  would focus on just the wire protocol - what the codepoints
>>> mean, how they are encoded, tunnel processing, router forwarding
>>> behaviour, errors & management etc.
>>> 
>>> Altho I'm not implying re-ECN is any more than a candidate, it
>>> would be a useful exercise to go through the contents of the
>>> re-ECN protocol spec <draft-briscoe-tsvwg-re-ecn-tcp-08> and
>>> check where you assume the different sections will end up. I've
>>> just done that, which is why I keep bringing up awkward
>>> questions.
>>> 
> 
> ________________________________________________________________ Bob
> Briscoe,                                BT Innovate & Design
> 
> 
> 
> _______________________________________________ re-ECN mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ re-ECN mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/re-ecn

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Thu, 7 Jan 2010 17:13:39 +0200

Hi,

> on getting the work items moving.

yes, I got it yesterday. I think this captures the points made at the BOF and during the follow-up discussion really well.

I myself have no further comments; I'll being the charter to the IESG/IAB for discussion.

Thanks,
Lars

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jan 2010 17:06:30 +0000

Leslie,

Thanks for this. I'm v happy with the milestones now. Glad to see 
Lars is happy too.

On reading thru, I've included one item inline to queue up: for if 
there's a future opportunity for mods...

At 14:42 07/01/2010, Leslie Daigle wrote:

>Hi,
>
>For the (public) record, here's the most recent version of the 
>charter.  Phil sent it along to Lars for his consideration, 
>yesterday.  I think we'll wait to hear feedback from him before 
>doing more serious mods on the charter -- I think (hope!) we're 
>really close, and can be focusing on getting the work items moving.
>
>
>visible at the transport layer in the end systems. With the output 
>of CONEX, it will be
>that exploit the CONEX output could be used for

sharing capacity,

[we seem to have omitted the primary, most generic use: 
accountability for contributing to congestion!]

>mitigating distributed
>A. the functionality / capability that is expected to be provided by 
>the CONEX mechanism itself, including its architectural features, 
>C. security goals - addressing 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
>
>congestion. 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.
>
>tentatively slated as Standards track. Depending on the bits that 
>are proposed to be used in the IP header and their semantics (eg Bit 
>48 in IPv4, ECN nonce), there may need to be further STD or INFO 
>documents to reassign the bits from their current definition(s) 
>(which would be subject to appropriate IESG and IETF review as necessary).
>
>
>>End of re-ECN Digest, Vol 11, Issue 2 *************************************
>>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 8 Jan 2010 11:33:07 +0100

Hi
 
Looks good as far as I can see. 
 
I have one question/comment however regarding the mechanism for IPv4. 
The milestone says "IPv4 specification sent to IESG (STD)"
This sounds reasonable but I recall that earlier it was considered as EXP for IPv4 or ?. Asking because I can imagine that people may have strong feelings esp. about the use for bit 48.   
Also I can see that the text says "tentatively slated as standards track". This may cause some confusion as the milestone says STD.
 
Regards
Ingemar

________________________________

Från: Leslie Daigle [mailto:[email-masked]]
Skickat: to 2010-01-07 15:42
Till: Ingemar Johansson S
Kopia: [email-masked]
Ämne: Re: [re-ECN] Complete draft Charter for proposed CONEX WG

Hi,

The purpose is

==

Leslie.

--

---

From: <[email-masked]>
Date: Fri, 8 Jan 2010 11:11:14 -0000

Idea is that we should try for STD - as the pkt structure is the key thing that needs to be standardised. There arent a whole lot of choices and  not sure that you could do expts to distnguish between them.
What track the various items are on is something that we expected the iesg would have input on, hence "tentatively slated". Perhaps could have been phrased better - anyway, it's in with the iesg now. 

Thanks
phil

> -----Original Message-----
> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: 08 January 2010 10:33
> To: Leslie Daigle; [email-masked]; Briscoe,RJ,Bob,XVR9 
> BRISCORJ R; Eardley,PL,Philip,DEE1 R
> Cc: [email-masked]
> This sounds reasonable but I recall that earlier it was 
> considered as EXP for IPv4 or ?. Asking because I can imagine 
> that people may have strong feelings esp. about the use for bit 48.   
> Also I can see that the text says "tentatively slated as 
> standards track". This may cause some confusion as the 
> milestone says STD.
>  
> Regards
> Ingemar
> 
>   Phil sent it along to Lars for his consideration, 
> yesterday.  I think we'll wait to hear feedback from him 
> before doing more serious mods on the charter -- I think 
> (hope!) we're really close, and can be focusing on getting 
> the work items moving.
> 
> 
> 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 
> in the end systems. 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.
> 
> 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. deployability goals - how the CONEX mechanism can be 
> deployed in networks (non vs ECN vs perhaps CONEX routers) 
> and end systems
> 
> [1] to detail the key functional and non-functional 
> [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)
> 
> A. for the timely transport of congestion information from 
> the destination to the sender,
> 
> B. for ensuring the trustworthiness of the CONEX information 
> (to mitigate the threats identified in 1C)
> 
> 4. Use cases -- possible uses of CONEX information, which 
> include controlling or reducing congestion and increasing 
> accountability for congestion. 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.
> 
> The output is Informational and Experimental, apart from #2 
> which is tentatively slated as Standards track. Depending on 
> the bits that are proposed to be used in the IP header and 
> their semantics (eg Bit 48 in IPv4, ECN nonce), there may 
> need to be further STD or INFO documents to reassign the bits 
> from their current definition(s) (which would be subject to 
> appropriate IESG and IETF review as necessary).
> 
> 
> trustworthiness of the CONEX information, including Spec of 
> one mechanism to WGLC (EXP)
> 
> Mar 2011 Transport-related Best practices for the transport 
> of congestion information from the destination to the sender, 
> including Spec of TCP modification to WGLC (EXP)
> 
> >>> people can't get an intuitive grasp of it. E.g. HIP would 
> have been 
> >>> unlikely to get anywhere without RFC4423. We know ConEx 
> hasn't been 
> >>> easy for newcomers to grasp, so we shouldn't fudge this issue.
> >>>
> use-cases 
> >>> other use-cases. This could become a README-FIRST if 
> written well, 
> >>> as it's difficult to introduce ConEx without describing 
> how it might 
> >>> be used.
> >> is more work. I wonder if the applicability statement can 
> be tweaked 
> >> for this purpose. We could add another "purpose": [3] to 
> provide an 
> >> intuitive explanation of the new concepts in CONEX
> >>
> > B. I'm not convinced we will be able to write a deployment 
> analysis of 
> > a protocol as yet to be defined - we can surely only write 
> >>> transport to set its expectation of congestion? - The 
> above EXP for 
> >>> e2e transport, - or within the ConEx-IP doc (if so, which 
> one? v4 or 
> >>> v6)? It would seem to fit better in the e2e transport 
> one, then the 
> >>> spec for TCP could provide an example of the complete 
> best practice.
> >> The IP doc defines packet the structure to carry CONEX 
> information  - 
> >> ie what the codepoints are and what they mean. "what they mean" of 
> >> course influences what the sending transport should do, but the 
> >> advice for the sending transport would be in the transport doc 
> >> [things like "send, as soon as possible, a Black codepoint 
> for every 
> >> loss or mark notified by the receiver". or whatever!]
> >>
> >> Thanks phil
> >>
> >>> would focus on just the wire protocol - what the codepoints mean, 
> >>> how they are encoded, tunnel processing, router forwarding 
> >>> protocol spec <draft-briscoe-tsvwg-re-ecn-tcp-08> and check where 
> >>> you assume the different sections will end up. I've just 
> done that, 
> >>> which is why I keep bringing up awkward questions.
> >>>
> >