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

<philip.eardley@bt.com> Tue, 20 November 2012 17:00 UTC

Return-Path: <philip.eardley@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391F521F84BA for <conex@ietfa.amsl.com>; Tue, 20 Nov 2012 09:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVuKNhYj3VuC for <conex@ietfa.amsl.com>; Tue, 20 Nov 2012 09:00:08 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id A124C21F87D2 for <conex@ietf.org>; Tue, 20 Nov 2012 09:00:06 -0800 (PST)
Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 17:00:05 +0000
Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.94]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Tue, 20 Nov 2012 17:00:05 +0000
From: philip.eardley@bt.com
To: conex@ietf.org
Date: Tue, 20 Nov 2012 17:00:04 +0000
Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt
Thread-Index: Ac2w4sycd+OJzzDDTzGlGcbz9daDbAVnFcLgAC8a+zA=
Message-ID: <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net>
References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net>
In-Reply-To: <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2012 17:00:10 -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: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] 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
conex@ietf.org
https://www.ietf.org/mailman/listinfo/conex