Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

From: <[email-masked]>
Date: Tue, 20 Nov 2012 17:00:04 +0000

Looks nice, here are some minor comments 

Thanks Phil 

==

S2
I found the first sentence rather awkward. I'm not sure it's needed anyway - could it be cut? 	

P5 para 2
<< For example
   traffic volume is the total number of bytes delivered, optionally
   over a specified time interval and over some aggregate of traffic
   (e.g. all traffic from a site).  While loss-volume is the total
   amount of bytes discarded from some aggregate over an interval.  The
   term congestion-volume is defined precisely in>>	
this seems to be missing a sentence on the lines:
And congestion-volume is the total amount of bytes that are congestion-marked from some aggregate over an interval; the term congestion-volume is defined precisely in...

p5 para 3
<<Also, the flow-state required for audit creates itself as
   it detects new flows.>>
this sentence is awkward, especially as 'itself' and 'it' (probably) refer to different things. 
?maybe "Also, the audit mechanism can automatically create the flow-state required when it detects a new flow"

<< There is a long standing argument over units of congestion: bytes vs
   Packets.... >>
I disliked this paragraph. It has several ideas that are hard to understand. It seems that it matters what the units of congestion are - but the examples fail to explain why. So it's confusing. 

I suggest shortening the para:
There is a long standing argument over units of congestion: bytes vs
   packets (see [I-D.ietf-tsvwg-byte-pkt-congest] and its references).
   This document does not take a position on this issue.
   However, the units of congestion must be an explicitly stated
   property of any proposed encoding, and the consequences of that
   design decision must be evaluated along with other aspects of the
   design.

S2.1
<<ConEx signals in IP packet headers from the sender to the network: .... 
ConEx Signal:  >>
This means that ConEx signals ConEx Signals (!)  
Perhaps:
ConEx allows a transport sender to add information in IP packet headers:
(please feel free to ignore if this has already had a lot of terminological debate!)

<<      Credit:  The transport is building up credit to allow for any
         future delay in expected ConEx signals (see Section 5.5.1)>> 

signals /Signals 

also, would 'potential' be better than 'expected'?

S3.2
<<   Proportionate Sanction:  To the extent that the audit might be
      subject to false hits, the sanction SHOULD be proportionate to the
      degree to which congestion is understated.  If audit over-
      punishes, attackers will find ways to harness it into amplifying
      attacks on others.  Ideally audit should, in the long-run, cause
      the user to get no better performance than they would get by being
      accurate.>>
1. suggest deleting " To the extent that the audit might be
      subject to false hits," - at least I don't understand why (and anyway it is badly phrased, since the audit causes the false hits so how can it be subject to them?) 

2. " no better performance than" - the sentence before suggests this should be "the same performance as"

S4.1
Think it would be worth mentioning that the naïve encoding is ok where everything is trusted.

S4.4
Last para - about packets vs bytes - seems odd here when S4.6 is about this issue. Suggest moving or deleting. 
(same comment for last sentence of S4.5)

S4.6
<<   The following comments apply generally to all the other encodings.>>
Don't understand "all the other". Can you delete "the other"?

S5.4.3 end of para 2
Think you could add "for instance" (since this is an example action, albeit the most likely?)

S5.4.3 para 4
<<   Note that the policing action is to introduce a throttle (delay
   through traffic) immediately upstream of the congestion policer.>>
don't understand "through" (no traffic is destined for policer). Simply: "(by delaying traffic)"?

S5.5 p19 para 1
<<Note that in the future it might prove to be desirable to
   provide advice on uniformly implementing sanctions, because otherwise
   insufficient sanctions impairs the ability to implement policy
   elsewhere in the network.>>
not sure you mean " uniformly implementing sanctions" (ie everyone has to implement in the same manner) - maybe "ubiquitous deployment of sanctions "?
	
S6
<< The ConEx abstract protocol described so far is intended to support
   incremental deployment in every possible respect.  >>
suggest "in several respects"

S6 para starting "Senders:"
" all the packets sent from that host using that protocol will be ConEx marked."
Think you mean "ConEx-enabled" 

Next para:
"      continue to send regular Not-ConEx packets as always."
Suggest delete " as always"

S6 "Forwarding:" sub-section, last sentence
<< Also, monitoring rest-of-path congestion is not
      accurate if there are congested non-ECN queues upstream of the
      monitoring point (Section 5.4.2).>>
(actually S5.4.2 doesn't explain this point.) 
?maybe you could say something more precise like:
"Also, monitoring of ECN-marks will result in overestimating rest-of-path congestion if there are congested non-ECN queues upstream of the monitoring point (Section 5.4.2)."

S8
<<      Signal Poisoning with 'Cancelled' Marking: >>
Suggest re-phrase, as "cancelled" marking hasn't been used as a term.

S8
<<  It is planned to document all known attacks and their defences
   (including all the above) in the RFC series.  In the interim,
   [Refb-dis] and its references should be referred to for details and
   ways to address these attacks.>>
I think it unlikely that the rfc series will actually do this. anyway, I don't think the sentences are needed - you referred  earlier to [Refb-dis] - and also made the main point, that a specific encoding will have to describe how it defends against likely attacks.

=======

Nits
S2
<< However, delay is too amorphous to use as a congestion metric.>> Is 'amorphous' the right word?

P5, para 1, penultimate line:
is motivated /are motivated

p6, para 2
deployment, which in turn
=>
deployment. This in turn 

page 5 para 3
<< ii) auditing at the edges, with limited per flow state, enables
   policy in the core, without any per flow state.>> 

maybe clearer: 
ii) auditing at the edges that uses limited per flow state, enables
   policy mechanisms in the core that don't use any per flow state.

p6 last word
congesting /congestion

S3.1 b.
<< Nonetheless, ConEx deployment need never be universal,
       and it is anticipated that some hosts and some transports may
       never support the ConEx Protocol and some networks may never use
       the ConEx Signals.>>
shorter & clearer:
Nonetheless,
it is anticipated that some hosts and some transports may
       never support the ConEx Protocol and some networks may never use
       the ConEx Signals.

S3.1 c.
ConEx signal / ConEx Signal

S3.1 D.
ConEx signal / ConEx Signal [4 TIMES]

Again in the next para. Also 3 instances in S5.5.1. Possibly elsewhere as well!

Refs
[Evol_cc] would be clearer as (I mean clearer for the reader of the main doc)
[Evolution-of-congestion-control]

S3.3 Network layer B.
<<what
          values they should be considered equivalent to by ConEx-aware
          elements>>
could be phrase cleaner?

S3.3 Security A.
<<strong audit algorithm>> - is 'strong' needed?

S4.1 last para
Naïve /naive

S5.3 para 2
It's /its

5.4
Could add ref to Section 5.5 after "auditing devices"

5.4.2 
End of para 1 is missing ")"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: 23 October 2012 06:54
To: 'ConEx IETF list'
Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

Hi,

This note issues the WGLC for

draft-ietf-conex-abstract-mech-06.txt

Please reivew the document and provide comments. The WGLC will close on the 20th of november.

For you convenience, the draft can be found at:

https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech

Regards, marcelo

_______________________________________________
conex mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/conex

---

From: John Leslie <[email-masked]>
Date: Tue, 20 Nov 2012 19:42:33 -0500

> Looks nice, here are some minor comments 

   I am delighted that Phil has responded -- this document has suffered
from too little feedback for too long. :^(

   Alas, I must honestly say I don't think it's ready to go to the IESG.

   I have over 300 words of red scribble on my paper copy, which I
won't reproduce here. Fundamentally, this document isn't clear about
its aims, leaves the reader guessing at the meaning of some important
terms, and states requirements which probably aren't actually required.

   First and foremost, if it intends to set requirements, that should
be clearly stated in the abstract, and the requirements in question
should either _be_ requirements or exceptions should be noted immediately
withing the listed requirement items.

   Whether or not this is a requirements document, some important terms
are not adequately defined. For example

- "flow" leaves me guessing how any node would decide what is within
  the "flow". Is this source+destination IP addresses? Does it include
  source+destination ports in protocols that have "port"? Does it include
  IPv6 Flow-ID?

- The interaction of "Policy", "Policing", "Audit", "Sanction", and
  "punishment" is (IMHO) to hard for the casual reader to grok. Some
  guidance about this needs to appear in the Introduction.

   The reader finds many things hard to follow without a familiarity
with a number of the Informative references. Informative references
should not be necessary to understanding an RFC (though hopefully
they will _improve_ one's understanding).

   Most network operators will choke at the amount of state this
document suggests maintaining in the Audit function. (Myself, I only
choke when I think of maintaining that much state during DDoS. ;)

   The idea of "Credit" fails to clarify whether the credit should
cover every packet in flight: we've had confusion on-list about that
exact question; and it shouldn't be left an open issue.

   If you persist until near the end of the document, you can find the
expectation that there will be multiple Audit functions along the path,
which mostly give less assurance to Policy functions that the naive
reader would expect. This, IMHO, should be clarified earlier (though
not in the Introduction).

   There are a number of details which discuss IPv4 implementations
of re-ECN, while we are chartered for an IPv6 implementation only.
(I can't guarantee this will upset current IESG members, but it
would have upset the ones that chartered us...)

   "Sanction" being "proportionate" to understatement of congestion
sounds like wishful thinking. With 100% auditing and 100% state,
this could be arranged; but it's pretty clear this document isn't
proposing 100% auditing.

   I don't find the inclusion of "Encodings" other than one we're
likely to use helpful, and I do find them distracting. YMMV, of course.

   The Security Considerations section lists a number if issues which
IMHO deserve to be noted but do not need to be solved (at all) for
an Experimental protocol.

   Most of my detailed comments seem more appropriate to be sent in
private email to a Document Editor (but I shall await WGC guidance
before doing so).

--
John Leslie <[email-masked]>

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 21 Nov 2012 13:27:48 +0000

Hi

First time I had time to read carefully through this document
The document is comprehensible and I don't find any serious issues with it.

One comment though on page 5, 3rd para.
" the flow-state required for audit creates itself as it detects new flows.  Therefore a flow will not fail if it is re-
   routed away from the audit box currently holding its flow-state. "

If I map ConEx to a 3GPP LTE use case, the audit functions are best placed in the eNodeB. When a new (long lived) flow is created it is preferably preloaded with credit marks which are stored in the auditor in the eNodeB which the terminal is "connected" to. When the terminal hands over to another eNodeB the credit marks will be lost.  This means that the ConEx markings will in this case be at least one RTT behind with a higher risk of false positives in the auditor in the new eNodeB
To avoid this the credit marks would need to be forwarded to the new eNodeB via e.g the X2 interface.

So my question is, is it needed to add a statement that mentions this ?

/Ingemar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: 23 October 2012 06:54
To: 'ConEx IETF list'
Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

Hi,

Regards, marcelo

---

From: John Leslie <[email-masked]>
Date: Wed, 21 Nov 2012 09:38:30 -0500

Ingemar Johansson S <[email-masked]> wrote:
> " the flow-state required for audit creates itself as it detects new
>  flows.  Therefore a flow will not fail if it is re-routed away from
>  the audit box currently holding its flow-state. "
> 
> If I map ConEx to a 3GPP LTE use case, the audit functions are best
> placed in the eNodeB. When a new (long lived) flow is created it is
> preferably preloaded with credit marks which are stored in the auditor
> in the eNodeB which the terminal is "connected" to. When the terminal
> hands over to another eNodeB the credit marks will be lost. This means
> that the ConEx markings will in this case be at least one RTT behind
> with a higher risk of false positives in the auditor in the new eNodeB

   I think it would be very helpful to work out wording for this -- in
network-layer terminology. (Long-Term-Evolution alphabet-soup is beyond
what we should expect of our readers.)

   If I understand you (not a sure thing, alas!), you're saying that
when a network-layer node has reason to know the path forwarding is
changing, it should insert extra ConEx Credit marks in order that an
Audit function in the new forwarding path not interpret congestion
it observes in the presence of ConEx-Not-Marked signals to be
understatement of congestion, which calls for "some sanction" to be
applied.

   (From Section 5.5.1, "if the balance ever goes negative, the audit
function can immediately start punishing a flow, without any grace
period.")

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 21 Nov 2012 19:01:11 +0000

Hi

I believe that it should be possible to write up a general statement without any additonal 3GPP soup. 
Such a statement would be like "when an existing flow is moved for instance due to a radio base station handover, any new auditor state that is created as a result of this should be pre loaded with the credit marks from...." my skills in english language fails me here, sorry.. please revise as needed.

/Ingemar

-----Original Message-----
From: John Leslie [mailto:[email-masked]] 
Sent: den 21 november 2012 15:39
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

> So my question is, is it needed to add a statement that mentions this ?

   I think it would be very helpful to work out wording for this -- in network-layer terminology. (Long-Term-Evolution alphabet-soup is beyond what we should expect of our readers.)

   If I understand you (not a sure thing, alas!), you're saying that when a network-layer node has reason to know the path forwarding is changing, it should insert extra ConEx Credit marks in order that an Audit function in the new forwarding path not interpret congestion it observes in the presence of ConEx-Not-Marked signals to be understatement of congestion, which calls for "some sanction" to be applied.

   (From Section 5.5.1, "if the balance ever goes negative, the audit function can immediately start punishing a flow, without any grace
period.")