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

[Leslie Daigle <[e-mail]>]

Hi,

(Catching up after a week of weather and being under it, and about to 
disappear for the holidaze):

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

Depending on your definition of "newcomer", I believe that is the 
Applicability Statement document.  "This is what CONEX is (and is not)". 
For hand-holding -- well, that was never a WG output, was it?

> more inline...

Ditto.

> 
> 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 3^rd 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.

I don't follow the logic -- EXP isn't !STD; it can also describe 
something which has effects on traffic.  I'm not entirely convinced the 
trustworthiness mechanism is free of potential effects on traffic?

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

I suspect it will be a challenge to capture the best practices 
generically (i.e., independent of transport), beyond what we might 
already express in the applicability statement?  Or, perhaps you could 
sketch out some examples of where you think we could find that dividing 
line?


Leslie.

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

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------