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

[<[e-mail]>]

Bob

Thanks, some follow-ups in-line (if your email doesn't crash my computer for 3rd time!! - anti-crashing measures mean my replies are labelled [phil[ but sorry bob's email is not indented/marked)

Phil, Leslie,

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)

[phil] I think people are ok with them being separate docs

2. Which numbers and letters mean separate docs, and which don't?

[phil] the list of docs is in the Milestones (there's no indecision!). Didn't see that as the purpose of the Output - which is more of an overall summary about what the WG's trying to do. On the specific topic of transport-related output, the docs are:
	*	INFO Best practices on 3A & B, ie transport of cong info & ensuring trustworhiness
	*	EXP TCP mod to do 3A, transport of cong info
	*	EXP one mechanism to ensure trustworthiness


		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.

[phil] I guess I don't mind deleting the "Note:..." text. 

[phil] But I think we have a somewhat different perspective. I'd like any capability negotiation to be the absolute minimum possible - the TCP mod doc is an EXP, make some assumptions, solve the main case, a revised doc can handle etc. Whereas I think you'd like it to solve all the capability negotiation in the doc, it will not get revised, or even if it does you introduce another migration problem / capability negotiation, etc. on balance, I suspect that capability negotiation is quite hard to get right and has only a small influence on whether conex is a success, so the WG should focus efforts on the important bits (esp defining IP).  


		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?

[phil] we'd had a crack (assuming it's obvious which things are Info and which Expt). But you bring up some good points below.

[phil] rather than the detail about possibilities you give below, I wonder instead we add:
"Depending on the bits that are proposed to be used in the IP header and their semantics (eg Bit 48, ECN nonce), there may need to be further STD or INFO documents to reassign the bits from their current definition(s)."

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.

[phil] ack