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

[Bob Briscoe <[e-mail]>]

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

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?


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

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.



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

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



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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design