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

From: <[email-masked]>
Date: Sat, 19 Dec 2009 13:59:15 -0000

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

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Dec 2009 02:22:15 +0000

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, [email-masked] 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)
>
>[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

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 22 Dec 2009 18:02:26 -0500

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.

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

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

-- 

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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 30 Dec 2009 00:19:40 +0000

Leslie,

At 23:02 22/12/2009, Leslie Daigle wrote:
>Hi,
>
>(Catching up after a week of weather and being 
>under it, and about to disappear for the holidaze):
>
>Bob Briscoe wrote:
>>Phil,
>Depending on your definition of "newcomer", I 
>believe that is the Applicability Statement 
>document.  "This is what CONEX is (and is not)". 

Hmmm. Not convinced.
One often cannot write a good "Read Me First" 
until other main docs have become fairly stable. 
Perhaps we should leave a placeholder for this later?

>>>doesn’t crash my computer for 3^rd time!!  
>>>Didn’t see that as the purpose of the Output  
>>>the WG’s trying to do. On the specific topic 
>>>of transport-related output, the docs are:
>>>
>>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 

I was assuming EXP = "STD-in-waiting" rather than !STD.

I agree that general constraints on 
trustworthiness mechanism*s* will affect traffic 
and need to be in an EXP (and later in a STD) doc.

But the currently given description of this doc 
calls for one example implementation of a 
trustworthiness mechanism, which I would say should be INFO.

If instead it was a doc about general constraints 
on the design of trustworthiness mechanisms, with 
an implementation as an example in an appendix, I 
would agree it could then be EXP (and it would 
provide somewhere for the normative text I reckon 
we will need - see next para). But that's not 
what the currently given description of this doc sounds like.

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

I gave an example bullet list on this list a 
month or so ago, repeated below, which might help 
this conversation to be a little more concrete.

Note: it is NOT intended to be definitive text, 
so pls don't anyone start wordsmithing each 
bullet on this list now, or questioning 
definitions of terminology (it's derived out of 
context from draft-briscoe-tsvwg-re-ecn-tcp-motivation-01).

===================================================================

  [...] the dropper algorithm [...] must meet the criteria below:

  o Minimal False Hits: It SHOULD introduce minimal false hits
  for honest flows;

  o Minimal False Misses: It SHOULD quickly detect and sanction
  dishonest flows, preferably at the first dishonest packet;

  o Transport Oblivious: It MUST NOT be designed around one
  particular rate response, such as TCP's, or one particular
  resource sharing regime such as TCP-friendliness, given an
  important goal is to give ingress networks the freedom to
  allow different rate responses and different resource sharing
  regimes - unilaterally without coordinating with downstream networks;

  o Sufficient Sanction: It MUST introduce sufficient loss in
  goodput so that sources cannot play off losses at the egress
  dropper against higher allowed throughput at the ingress policer;

  o Manage Memory Exhaustion: It SHOULD be able to counter
  state exhaustion attacks. For instance, if the dropper uses
  flow-state, it should not be possible for sources to exhaust
  its memory capacity by gratuitously sending numerous packets,
  each with a different flow ID

  o Identifier Accountability: It MUST NOT be vulnerable to
  'identity whitewashing', where a transport can label a flow
  with a new ID more cheaply than paying the cost of continuing
  to use its current ID;

Cheers

Bob

>>And I suggest we can't easily start the first 
>>one until after the other two (contrary to the milestone list).
>>
>>>"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:
>>>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.
>>>
>>>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] 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 
>>>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).
>>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.
>>
>>>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.