From philip.eardley@bt.com Tue Nov 20 09:00:10 2012 Return-Path: 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 ; 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 ; 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 ; 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: To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 17:00:10 -0000 Looks nice, here are some minor comments=20 Thanks Phil=20 =3D=3D S2 I found the first sentence rather awkward. I'm not sure it's needed anyway = - could it be cut? =09 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>>=09 this seems to be missing a sentence on the lines: And congestion-volume is the total amount of bytes that are congestion-mark= ed from some aggregate over an interval; the term congestion-volume is defi= ned precisely in... p5 para 3 <> this sentence is awkward, especially as 'itself' and 'it' (probably) refer = to different things.=20 ?maybe "Also, the audit mechanism can automatically create the flow-state r= equired 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 examp= les fail to explain why. So it's confusing.=20 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 <> This means that ConEx signals ConEx Signals (!) =20 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)>>=20 signals /Signals=20 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 b= e subject to them?)=20 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=EFve encoding is ok where ev= erything is trusted. S4.4 Last para - about packets vs bytes - seems odd here when S4.6 is about this= issue. Suggest moving or deleting.=20 (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 <> not sure you mean " uniformly implementing sanctions" (ie everyone has to i= mplement in the same manner) - maybe "ubiquitous deployment of sanctions "? =09 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 mar= ked." Think you mean "ConEx-enabled"=20 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.)=20 ?maybe you could say something more precise like: "Also, monitoring of ECN-marks will result in overestimating rest-of-path c= ongestion 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 do= n'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 describ= e how it defends against likely attacks. =3D=3D=3D=3D=3D=3D=3D Nits S2 << However, delay is too amorphous to use as a congestion metric.>> Is 'amo= rphous' the right word? P5, para 1, penultimate line: is motivated /are motivated p6, para 2 deployment, which in turn =3D> deployment. This in turn=20 page 5 para 3 << ii) auditing at the edges, with limited per flow state, enables policy in the core, without any per flow state.>>=20 maybe clearer:=20 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 w= ell! Refs [Evol_cc] would be clearer as (I mean clearer for the reader of the main do= c) [Evolution-of-congestion-control] S3.3 Network layer B. <> could be phrase cleaner? S3.3 Security A. <> - is 'strong' needed? S4.1 last para Na=EFve /naive S5.3 para 2 It's /its 5.4 Could add ref to Section 5.5 after "auditing devices" 5.4.2=20 End of para 1 is missing ")" -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of m= arcelo 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 From john@jlc.net Tue Nov 20 16:42:35 2012 Return-Path: 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 3FDF521F872D for ; Tue, 20 Nov 2012 16:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.385 X-Spam-Level: X-Spam-Status: No, score=-106.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XTYUjXmDk84M for ; Tue, 20 Nov 2012 16:42:34 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6C721F870A for ; Tue, 20 Nov 2012 16:42:33 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 29A7333CE3; Tue, 20 Nov 2012 19:42:33 -0500 (EST) Date: Tue, 20 Nov 2012 19:42:33 -0500 From: John Leslie To: philip.eardley@bt.com Message-ID: <20121121004233.GC28297@verdi> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 00:42:35 -0000 philip.eardley@bt.com wrote: > > 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 From ingemar.s.johansson@ericsson.com Wed Nov 21 05:28:05 2012 Return-Path: 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 025EB21F8651 for ; Wed, 21 Nov 2012 05:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 VLxCexBGlClf for ; Wed, 21 Nov 2012 05:28:04 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B521F84B5 for ; Wed, 21 Nov 2012 05:28:03 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-89-50acd6e2d9b6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FA.99.11564.2E6DCA05; Wed, 21 Nov 2012 14:28:02 +0100 (CET) Received: from ESESSHC001.ericsson.se (153.88.183.21) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 21 Nov 2012 14:27:58 +0100 Received: from ESESSMB205.ericsson.se ([169.254.5.136]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 14:27:49 +0100 From: Ingemar Johansson S To: "conex@ietf.org" Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt Thread-Index: AQHNx1njVg+tGahsb06Ne07rnDfUVZf0Q9Zw Date: Wed, 21 Nov 2012 13:27:48 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje6ja2sCDB6skbY4dO0nowOjx5Il P5kCGKO4bFJSczLLUov07RK4Ml5t2MFa8Ie3Yv+l16wNjEu4uxg5OSQETCTW98xihbDFJC7c W8/WxcjFISRwklHi8pXljBDOTkaJ48s7oDJLGCV2XOsEa2ETsJFYeeg7I4gtIqAqsfzlXTCb WcBK4svxv8wgtrCAs8T2k2dYIWpcJKbe/AdkcwDZRhIfTtuBhFmAWqdOessIEuYV8Ja4cSkD YtVpRom/S3rBWjkFoiW2zGlkB7EZBWQl7n+/xwKxSlzi1pP5TBAfCEgs2XOeGcIWlXj5+B/U Z4oSH1/tgzpNR2LB7k9sELa2xLKFr8HqeQUEJU7OfAI2U0hAV2L9jqvsExglZiFZMQtJ+ywk 7bOQtC9gZFnFyJ6bmJmTXm64iREYQQe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGCNPz/e2zJVpco+SWyPLIXz6z5U/rPlqR5h0XQ9v+OOkZcniNXWm U+WfySES3zOMdJ5/vnDtyDfewh/c8/eKK/K0+9g0MPpy/dj8diPnijyGtQUXSrv2BPTrTA6b 0+01QXjjXA7ZuR8OrP117l7BMpcalWLP1PzEJROFBP5sX6gTL8G956ZFkxJLcUaioRZzUXEi AKr+OTpuAgAA Cc: Ingemar Johansson S 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 13:28:05 -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 pre= loaded with credit marks which are stored in the auditor in the eNodeB whic= h the terminal is "connected" to. When the terminal hands over to another e= NodeB the credit marks will be lost. This means that the ConEx markings wi= ll in this case be at least one RTT behind with a higher risk of false posi= tives 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: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of m= arcelo 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 From john@jlc.net Wed Nov 21 06:38:31 2012 Return-Path: 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 BBE7621F8665 for ; Wed, 21 Nov 2012 06:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 QsdPHCpNrkI2 for ; Wed, 21 Nov 2012 06:38:31 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2458D21F8522 for ; Wed, 21 Nov 2012 06:38:30 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id AB30333CA4; Wed, 21 Nov 2012 09:38:30 -0500 (EST) Date: Wed, 21 Nov 2012 09:38:30 -0500 From: John Leslie To: Ingemar Johansson S Message-ID: <20121121143830.GD28297@verdi> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:38:31 -0000 Ingemar Johansson S wrote: > > 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 ? 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.") -- John Leslie From ingemar.s.johansson@ericsson.com Wed Nov 21 11:01:15 2012 Return-Path: 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 C118321F8447 for ; Wed, 21 Nov 2012 11:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 HiJ+8JXySQ9n for ; Wed, 21 Nov 2012 11:01:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 44D8621F8446 for ; Wed, 21 Nov 2012 11:01:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-a3-50ad24f95515 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 25.0F.11564.9F42DA05; Wed, 21 Nov 2012 20:01:13 +0100 (CET) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 21 Nov 2012 20:01:12 +0100 Received: from ESESSMB205.ericsson.se ([169.254.5.136]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 20:01:12 +0100 From: Ingemar Johansson S To: John Leslie Thread-Topic: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt Thread-Index: AQHNx1njVg+tGahsb06Ne07rnDfUVZf0Q9ZwgAAIcgCAAFF3kA== Date: Wed, 21 Nov 2012 19:01:11 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA04F48B@ESESSMB205.ericsson.se> References: <508630EE.8060305@it.uc3m.es> <9510D26531EF184D9017DF24659BB87F33F3643D42@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F33F3644323@EMV65-UKRD.domain1.systemhost.net> <81564C0D7D4D2A4B9A86C8C7404A13DA04F232@ESESSMB205.ericsson.se> <20121121143830.GD28297@verdi> In-Reply-To: <20121121143830.GD28297@verdi> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje5PlbUBBlc3iVocuvaT0eL9hfOM DkweS5b8ZPI4NvcwcwBTFJdNSmpOZllqkb5dAlfGlmtHWQruClfcn5/RwPiCv4uRg0NCwESi 94lVFyMnkCkmceHeerYuRi4OIYGTjBKX7u5ihXB2Mkp03u1nh3CWMEpMPbuAFaSFTcBGYuWh 74wgtoiAnMSvsw/AbGYBVYl9j2axgNjCAs4S20+eYYWocZGYevMfK8hmEQEnialXBEDCLEDl y78tZwexeQW8Jc5OO88CsWsdk8S+aR/YQBKcAtoSi27+ApvPKCArcf/7PRaIXeISt57MZ4J4 QUBiyZ7zzBC2qMTLx/9YIWxFiY+v9kHdpiOxYPcnNghbW2LZwtfMEIsFJU7OfAI2U0hAV2L9 jqvsExglZiFZMQtJ+ywk7bOQtC9gZFnFyJ6bmJmTXm64iREYUwe3/NbdwXjqnMghRmkOFiVx Xq6k/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIsLDgtnyYnuYVfUOj730kwPO++T3X26 K9wOuSROWrAw659Qd5z8XkOuT9ec3MLUrhY5KyYfqStaHKEblStU96U2ZNX37F2rJ6w5MuXh VsstHGc2Tdd4KVhyJzRwU5q5ZGJ2dX6QuG7P03sWCg9WTyu4Y+osWG299Pmk5M6s5UZhk5Yo rBA9pMRSnJFoqMVcVJwIAA7Ejqx3AgAA Cc: "conex@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:01:15 -0000 Hi I believe that it should be possible to write up a general statement withou= t any additonal 3GPP soup.=20 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 create= d 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 neede= d. /Ingemar =20 -----Original Message----- From: John Leslie [mailto:john@jlc.net]=20 Sent: den 21 november 2012 15:39 To: Ingemar Johansson S Cc: conex@ietf.org Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt Ingemar Johansson S wrote: >=20 > One comment though on page 5, 3rd para. > " the flow-state required for audit creates itself as it detects new =20 > flows. Therefore a flow will not fail if it is re-routed away from =20 > the audit box currently holding its flow-state. " >=20 > If I map ConEx to a 3GPP LTE use case, the audit functions are best=20 > placed in the eNodeB. When a new (long lived) flow is created it is=20 > preferably preloaded with credit marks which are stored in the auditor=20 > in the eNodeB which the terminal is "connected" to. When the terminal=20 > hands over to another eNodeB the credit marks will be lost. This means=20 > that the ConEx markings will in this case be at least one RTT behind=20 > with a higher risk of false positives in the auditor in the new eNodeB=20 > To avoid this the credit marks would need to be forwarded to the new=20 > eNodeB via e.g the X2 interface. >=20 > 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 netw= ork-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 t= he new forwarding path not interpret congestion it observes in the presence= of ConEx-Not-Marked signals to be understatement of congestion, which call= s for "some sanction" to be applied. (From Section 5.5.1, "if the balance ever goes negative, the audit funct= ion can immediately start punishing a flow, without any grace period.") -- John Leslie