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

[Bob Briscoe <[e-mail]>]

Phil,

One new question: Which doc do you see as 
"Newcomers, Read Me First for an overview of ConEx"?

more inline...

At 13:59 19/12/2009, [e-mail] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CA80B3.735951AE"
>
>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)
>
>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!).

[BB]: As I said, and you ack'd, it wasn't clear (to me).

>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
[BB]: I think (3B) one example of a 
trustworthiness mechanism shouldn't need anything 
to be standardised for interworking, so it could 
probably be INFO, rather than EXP.

Nonetheless, these three bullets aren't quite 
right. We will need some generic constraints on 
transports and a parallel set of generic 
constraints on trust mechanisms. They will 
probably need to be normative, not just 
informative. But if we follow the above approach, 
we won't have anywhere to put them.

Perhaps the three docs need to be EXP, EXP & INFO respectively?
And I suggest we can't easily start the first one 
until after the other two (contrary to the milestone list).

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

[BB]: With the experience of working out the 
capability negotiation for re-ECN (which was 
straightforward to implement), I figure it won't 
be that hard to do a similar exercise for ConEx for all cases likely to arise.

And, as you point out, half doing the job creates 
yet another migration problem later.

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

[BB]: Yes, that text is good. That would give the 
necessary signals to the IESG.

s/Bit 48,/Bit 48 in IPv4,/

To placate concerns, I also suggest we append 
"... which would be subject to the appropriate 
level of IESG and IETF review if they became necessary."

Cheers


Bob




________________________________________________________________
Bob Briscoe,                                BT Innovate & Design