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

[Bob Briscoe <[e-mail]>]

Phil, Leslie,

[In response to complaints, I'm re-sending this with a plain text 
variant as well as HTML - apologies for not doing this first time.]

I'm happy with the agreement so far (mainly on the intro text), but 
i'm afraid I have some issues with the intended outputs of the w-g, 
listed here, then details inline:

1. Separate IP spec? (I've started separate thread on this)
2. Which numbers and letters mean separate docs, and which don't?
3. Scope of transport spec?
4. #2 as stds track?
5. A nit.

At 11:14 14/12/2009, [e-mail] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CA7CAE.97FAE246"
>
>it would be great if we could get this to Lars in the next couple of 
>days. Please send any more comments asap
>thanks!
>phil
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of [e-mail]
>Sent: 08 December 2009 15:29
>To: [e-mail]
>Subject: [re-ECN] Complete draft Charter for proposed CONEX WG
>
>Intended output of the WG:
>
>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)
I notice we've implicitly decided to write the ConEx-IP specs 
separately from TCP and other transports. The alternative is to write 
one spec for ConEx-TCP/IP including additional generic guidelines for 
all transports. On balance I believe separating IP out is the best 
course, but I'm not certain and I'm willing to be persuaded...

See separate thread I will start on this issue.

>3. Transport-related Best practices and specifications:
>
>A. for the transport of congestion information from the destination 
>to the sender,
>
>B. for ensuring the trustworthiness of the CONEX information

In general, it would be better to be specific on what docs you are 
expecting. The numbers and letters seem to be designed to hide indecision ;)

Is 3A a different document to 3B? I hope so.
The implementer of 3A (OS coder) will be a different type of beastie 
to that for 3B (network policing box coder).

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

How about:
"Capability negotiation is only in scope to the extent that one ConEx 
host needs to know the capabilities of the other end that are 
necessary for ConEx to interwork. Otherwise capability negotiation is 
out of scope."

Reasoning:
The spec of the transport should surely be whatever is necessary to 
implement it. If capability negotiation is necessary, it is in scope. 
If not it's out of scope.

If there are different types of legacy out there that each require a 
ConEx host to behave in one of n different ways, we need to handle 
them all, whether n=1 or 3. We can't handle some of them, and hope we 
can handle the others later.

E.g. I believe a basic level of capability negotiation will be 
necessary for TCP, but not for RTCP.

Consider TCP-ECN. The way TCP was written doesn't work well for 
ConEx, because the feedback loses any more than 1 ECN mark per RTT. 
If we specify a ConEx-specific feedback upgrade to a TCP receiver 
(3A), the sender needs to know whether the meaning of the feedback is 
legacy or new.

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

At what point do we need to decide which track each doc is on? Surely 
best to have a crack at that during chartering?

Bear in mind the only bit we've found suitable in IPv4 (bit 48) is 
"reserved for future use". That's not even experimental track, let 
alone stds track. I would be v surprised if the IESG give away the 
last bit in the IPv4 header without an experiment first - and an 
experiment that must prove it can be unwound if it fails (so the bit 
could be reused elsewhere).

RFC4727, RFC3692 & particularly RFC2780 define a fairly 
straightforward process for experimental use of values in the IP 
header (and other base headers). Assuming for a moment, that we use 
bit 48 in IPv4, this implies work items for a charter would need to include:

ONLY IF NECESSARY:
2A. (STD) Reassign value 1 of IPv4 bit 48 from 'reserved' to 'experimental use'
    (not specifically for ConEx)
    Also possibly describe conditions on experiments, e.g.:
    - confined in space and in time
    - multiple simultaneous experiments with same value would need v 
strong case


2B. (EXP) ConEx protocol in IPv4 (using experimental bit 48 in IPv4)
2C. (STD) ConEx protocol extension hdr in v6

We also have to include contingency in the charter in case we cannot 
find a viable ConEx encoding without reusing the ECN nonce codepoint. 
Then the charter needs to allow us to write a doc to change the 
status of the ECN nonce (RFC3540) from expt to historic, BUT ONLY IF 
ABSOLUTELY NECESSARY. It would also have to update DCCP and SCTP, 
which are stds track. In summary:

ONLY IF NECESSARY:
2D. (INF/STD) Move ECN nonce in IPv4&6 (RFC3540) from Experimental to Historic

[When we designed re-ECN, we found we needed to reuse the ECN Nonce 
codepoint. Given ConEx provides a superset of the Nonce capabilities, 
and given no-one is aware of the Nonce ever having been implemented, 
except in TCP on the machine of the author, moving it to historic 
seems reasonable. This applies for use of the nonce in all of TCP, 
DCCP & SCTP - all specified but never tested through implementation.]

>Milestones

Finally, a nit. I agree with others that the milestone list is hard to follow.

It would help (me) to have the output identifier in a visible column, 
for example:

Feb 2010 1A     Functionality statement: Internet-Draft
Mar 2010 1A,B,C Applicability statement: Internet-Draft
     ....
Jun 2010 2A     CONEX IPv4 specification: WG draft
     ....


Cheers


Bob

>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
>
>_______________________________________________
>re-ECN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design