From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Jun 3 05:59:37 2013 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 958B021F96ED for ; Mon, 3 Jun 2013 05:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwunWza20Lpw for ; Mon, 3 Jun 2013 05:59:33 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id CDEF821F965A for ; Mon, 3 Jun 2013 05:59:32 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E5D8B601C9; Mon, 3 Jun 2013 14:59:30 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id DEDB7601C8; Mon, 3 Jun 2013 14:59:30 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: jiyengar@fandm.edu Date: Mon, 3 Jun 2013 14:59:30 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306031459.30749.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Review of draft-ietf-conex-tcp-modifications-02 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: Mon, 03 Jun 2013 12:59:37 -0000 Hi Jana, thank you for your feedback. We just uploaded a new version for addressing= =20 quickly the last two ToDo: 1. Sending Credits -> A ConEx sender should maintain flightsize number of packets as credit= s=20 (in CA) 2. Loss of ConEx infos -> A ConEx sender should detect this case and send further credits But there are actually still some open questions mainly regarding the credi= ts: 1) What's the right reaction if ConEx markings get lost? 2) How to detect false positives of the audit at the sender? 3) How to incentives a sender to send right markings at the right time (e.g= =2E=20 to not send credits instead of L/E markings)? I'm going to send separate emails now to further explain these points and=20 hopefully discuss these questions on the list. Mirja On Friday 31 May 2013 19:55:06 Janardhan Iyengar wrote: > Mirja, Richard, all > > A bit late, I'm sending along my review > of draft-ietf-conex-tcp-modifications-02. I noticed that -03 came along > while I was reading the -02 version; I'm also happy to review later > versions. > > Overall, the text could use some tightening up. Some text may need to be > rewritten (I've suggested some below), and some could be eliminated > altogether. My major feedback at this time would be that the draft should > focus on mechanisms that are clear and are to be specified (such as LEG a= nd > CEG counts, for example). Other mechanisms that are either nascent or are > not yet fully specified ought to be left out from this document (such as > the more accurate ECN marking). More specific details follow. > > 1. Introduction: > - "ConEx is a ...": cite RFC 6789. For someone who hits this draft, it is > not clear where to go to find more about ConEx itself. > - End paragraph after "use ConEx with the Transmission Control Protocol > (TCP)." > > - Suggested restructuring: > + Move last paragraph "ConEx is currently/will be defined as an > destination option for IPv6..." up here to the beginning of the second > paragraph. > + Continue paragraph with "The ConEx signal is based on loss or ECN mar= ks > ..." > + Modify "loss or ECN marks" in the above sentence to "Explicit > Congestion Notification (ECN) marks". > > - Suggested rewording for paragraph "With standard TCP ...": > "This document describes mechanisms for TCP both with and without the > Selective Acknowledgment (SACK) extension [RFC2018]. However, ConEx > benefits from more accurate information about the number of packets dropp= ed > in the network. We therefore recommend using the SACK extension when using > TCP with ConEx." > > - Modify: "Explicit Congestion Notification (ECN) is defined in such a way > ..." to "ECN is defined in such a way ..." > > - This paragraph about more information than ECN seems unnecessarily > detailed. One sentence ought to be enough. Something like: "In addition to > standard ECN and SACK feedback, an extension described in [ > draft-kuehlewind-conex-accurate-ecn] shows how more accurate ECN feedback, > especially useful in the case of multiple markings within the same > roundtrip time (RTT), can be obtained." > > > 2: Sender-side Modifications: > - "MUST negotiate for both SACK and ECN or the more accurate ECN feedback > ..." : This strikes me as an odd MUST. SHOULD seems adequate. > - Using "SACK-accECN-Conex" instead of "Full-Conex" seems better > descriptive. > - "A ConEx sender MUST expose congestion to the network...": A compliant > Conex sender has to follow a Conex spec for exposing congestion; that can > be assumed here, without having a MUST in this document. Perhaps cite the > v6 options draft here without specifying here what a Conex sender MUST do. > - "A TCP sender SHOULD account congestion byte-wise (and not packet-wise)= ": > Cite draft-ietf-tsvwg-byte-pkt-congest or justify otherwise. > - "As network congestion is usually byte-congestion ...": Is this really > the case? Cite. > > > 3: Accounting Congestion: > - The writing in this section can be cleaned up. For instance, "... is > explained in the next section." should specify the section number. > - "A TCP sender SHOULD account congestion byte-wise (and not packet-wise) > ...": Cite draft-ietf-tsvwg-byte-pkt-congest. > - "The subtraction of bytes which have been ConEx marked from both counte= rs > is explained in the next section.": What does "subtraction of bytes" mean? > - "If equal sized packets ...": This sentence needs to be rewritten. > Difficult to read and follow. > - "If a sender sends different sized packets ...": difficult to follow as > well. I understand what it says, but it needs to be rewritten to be clear. > - "ECN is an IP/TCP mechanism ...": cite RFC3168. > - "A receiver can support the accurate ECN feedback scheme ...": cite. It > may be better to structure > - "Note the change in in the SACK information can also be negative if the > number of acknowledged bytes increases.": Not clear. Do you mean to say if > the number of acked bytes decreases? > - What are the variables is_after_dup and num_dup in the DeliveredData > expression? Please describe them before the equation or immediately after. > > 3.1.2: Classic ECN Support: > - It is non-trivial for a sender to determine when delayed acks will be > sent by the receiver, in particular with bidirectional data transfer. I > would be careful about suggesting such heuristics without getting into > details. Is this "Advanced Compatibility" really practical or necessary? > > 3.2: Loss detection with/without SACK: > - "assuming equal sized segments such that the retransmitted packet will > have the same number of header as the original ones." You cannot make this > assumption. There are commonly used stacks that will retransmit different= ly > sized segments, and even combine retransmitted bytes with new bytes within > a segment. This assumption is not critical, and so I would suggest droppi= ng > it from the text. > > - jana =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Jun 3 06:09:44 2013 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 9F92721F92FC for ; Mon, 3 Jun 2013 06:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhllGGwrpEMO for ; Mon, 3 Jun 2013 06:09:39 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F46221F8E8F for ; Mon, 3 Jun 2013 06:09:38 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 39934601CA for ; Mon, 3 Jun 2013 15:09:38 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 33BEB601C9 for ; Mon, 3 Jun 2013 15:09:38 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Mon, 3 Jun 2013 15:09:38 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201306031509.38049.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] 1) Loss of ConEx information 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: Mon, 03 Jun 2013 13:09:44 -0000 Hi, it can happen that ConEx information can get lost, e.g. a packet with a ConEx marking gets drop at a full router queue or the traffic gets rerouted and a new audit element does not have the old credit state. This might be a problem if an audit starts penalizing a flow because of this wrong information even though the sender has done nothing wrong. The question is how to handle this case? And also where to document what the right behavior of the audit and sender should be? I don't think we should try to retransmit any lost marking. Especially the L and E markings will be out-dated by the time of the retransmit. Thus the only solution is to send credits instead to keep the audit happy. But how to detect that ConEx information got lost? Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Jun 3 06:23:51 2013 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 90B2E21F96D9 for ; Mon, 3 Jun 2013 06:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJTLbotXQHYO for ; Mon, 3 Jun 2013 06:23:46 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6062821F95E9 for ; Mon, 3 Jun 2013 06:23:43 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id A246C601CA for ; Mon, 3 Jun 2013 15:23:37 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9CB39601C9 for ; Mon, 3 Jun 2013 15:23:37 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Mon, 3 Jun 2013 15:23:37 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201306031523.37193.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] 2) False positives of the audit 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: Mon, 03 Jun 2013 13:23:51 -0000 Hi, this question is directly related to the first one. If we have not done anything wrong at the sender but the audit still penalizes us because of wrong information at the audit, we need to detect this case at the sender and do something, e.g., as just proposed, send more credits. My only guess right now, how to detect such a false positive of the audit at the sender is, that if we see congestion (loss or ECN) for more than one RTT eventhough we have reduces our sending rate it must be a false positive. Thus in the worst case, we will see a large number of losses (upto all) induced by the audit. This will cause the sender to send further ConEx L marking and might lead to another throttling by the policer. If the audit drops too less packets on the other hand, it is not a sufficient penalty and FEC might be able to compensate (at least for shorter transmissions). Thus whenever there is a false positive by the audit, I currently would assume that this would strongly slow down or stop the transmission. But with the risk of loosing ConEx marked packets in the network and also not having sufficiently accurate ECN feedback, there will always be false positives. Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Mon Jun 3 06:39:08 2013 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 EF60221F991E for ; Mon, 3 Jun 2013 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAultAMOaTDx for ; Mon, 3 Jun 2013 06:39:03 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id BEF1421F9929 for ; Mon, 3 Jun 2013 06:39:03 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2AEE7601CC for ; Mon, 3 Jun 2013 15:39:02 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2801B601CB for ; Mon, 3 Jun 2013 15:39:02 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org Date: Mon, 3 Jun 2013 15:39:01 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201306031539.01763.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] 3) Incentive to send right markings 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: Mon, 03 Jun 2013 13:39:09 -0000 Hi, as long as the audit function counts credits the same way as it does count L/E marks, there is no incentive for a ConEx sender to send the right marking at the right time. And note, the goal of ConEx is to expose the current congestion level; thus L/E marks should be send as soon as the congestion has occurred and not earlier or not too late. More specifically the problem is, that a TCP sender has to send a large number of credits during Slow Start. Thus as long as the total number of losses + CE markings is smaller than the number of send credits, there is no incentive to send any L/E ConEx marks. Another case is if a token-bucket policer is used, the sender could simply send ConEx marking whenever the bucket would overflow (even though there has been not congestion). We can limit the number of L/E (that can be accounted at the audit) to at max to number of actually seen losses and CE marks. But we cannot do something like this for the credits as the credits should be send before the congestion occurs. I would proposed to give the credits a slight different meaning. Instead of having the credits forever sitting in the audit, they should be 'used' whenever congestion occurs. Thus as long as the L/E marks have not been sent yet and thus the audit is negative (not regarding the credits), the number of credits should be reduced somehow. We are currently still thinking about the details on this. I believe this would not solve the problems completely, but would help a lot. Any feedback and thoughts on this are very welcome! Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Jun 4 09:27:24 2013 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 1928021F9CD2 for ; Tue, 4 Jun 2013 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE0fPt1QSPJU for ; Tue, 4 Jun 2013 09:27:09 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D575921F9E79 for ; Tue, 4 Jun 2013 07:12:28 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D1CDE601FB; Tue, 4 Jun 2013 16:12:25 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CC7BE601FA; Tue, 4 Jun 2013 16:12:25 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: conex@ietf.org, Bob Briscoe , Matt Mathis Date: Tue, 4 Jun 2013 16:12:25 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> Subject: [conex] Review of draft-ietf-conex-abstract-mech-06 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, 04 Jun 2013 16:27:24 -0000 Hi, sorry for the very late review. The draft reads actually very well. I only have some high level comments: 1) The very long title of Figure 1 was kind of confusing me. 2) Section 'Overview' is very long (for an overview). Don't know if per-flow state, byte vs. packet and partial deployment needs to be discussed here. Maybe think about a subsection on discussion points instead (which could also include some discussion on attacks against the audit). On the other hand potentially introduce briefly the credit concept here. 3) Maybe define the term 'congestion signal' in section 2.1 4) I'm not sure that section 4.6 is at the right postion as it seems to me more related to requirements on the encoding. 5) Maybe address briefly how to handle ConEx-not-Marked and not ConEx-capable packets (not only for partial deployment but also in regular operation). They need to be limited somehow as well, otherwise a sender can easily cheat by sending ConEx-not-Marked. And this has to be done by the policer (and not the audit though). 8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss estimation. 9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of credits is well enough specified here. My personal option is that credits should somehow get invalid (at some point in time). This is left open in the current text. 10) In section 6 it is stated that 'Networks MUST NOT change ConEx marked packets to not_ConEx. [...]'. Maybe move this to the requirement section, otherwise it might be easily overread. 11) Security Considerations lists a number of attacks. Shouldn't this document also give hints how to handle these attacks? Especially for the 'Dragging Down a Spoofed Flow ID', I can't really come up with a good solution...? Mirja From mirja.kuehlewind@ikr.uni-stuttgart.de Tue Jun 4 11:34:21 2013 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 E3B0421F8E89 for ; Tue, 4 Jun 2013 11:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyiUdnisPiOH for ; Tue, 4 Jun 2013 11:34:16 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4086521F9B0C for ; Tue, 4 Jun 2013 11:14:23 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 093A960204; Tue, 4 Jun 2013 20:14:14 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 019D3601FD; Tue, 4 Jun 2013 20:14:14 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Tue, 4 Jun 2013 20:14:13 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306042014.13729.mirja.kuehlewind@ikr.uni-stuttgart.de> Subject: Re: [conex] My notes on abstract audit 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, 04 Jun 2013 18:34:21 -0000 Hi Matt, I know you've been sending this mail a long time ago but I had another look= at=20 it just now. And I realized that you took another assumption on the meaning= =20 of credits at the audit that I'm currently doing in the in TCP mod draft. In your notes you assume that the credit counter will be reduced in the aud= it=20 whenever the balance is negative and a new congestion mark arrives. My assumption was so far, that the credits you send sit forever in the audi= t=20 (expect route changes or other state resets). I believe this is nowhere clearly specified and we need to find a solution= =20 here. Anyway, both proposal for the sender algorithm (when to send credit) cannot= =20 handle the case when the state gets actually reset at the audit and thus wi= ll=20 cause the audit to (wrongly) penalize a connection in this case. Mirja On Thursday 02 August 2012 18:59:12 Matt Mathis wrote: > The URL below points to a document (in Google docs) that describes a > framework for exploring the audit design space. The intent is to get > all of the issues on the table such that we can explore the tradeoffs > between various aspects of the problem. The doc isn't done, but I > don't have any time for it in the near future. > > This document is publicly visible and has public comment permission. > Comment by highlighting a passage and right clicking (control-click?) > to get a menu and select comment. > > If people are interested in editing, I can turn on write permissions. > > Example ConEx credit and audit algorithms - > https://docs.google.com/document/d/1bwGKLGEcleHy2LvnfVFWIX_Qc3ZioDf1EpzgB= uj >Lm1g/edit > > Thanks, > --MM-- > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From bob.briscoe@bt.com Tue Jun 4 13:11:30 2013 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 743E721F9232 for ; Tue, 4 Jun 2013 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBM2AZCBvRAK for ; Tue, 4 Jun 2013 13:11:20 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 45BE121F9AFF for ; Tue, 4 Jun 2013 12:12:55 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Jun 2013 20:12:54 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 4 Jun 2013 20:12:53 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Tue, 4 Jun 2013 20:12:50 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.133.144]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r54JCmTJ012702; Tue, 4 Jun 2013 20:12:49 +0100 Message-ID: <201306041912.r54JCmTJ012702@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 4 Jun 2013 20:12:38 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: conex@ietf.org Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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, 04 Jun 2013 20:11:30 -0000 Mirja, Tx for this. Matt & I were recently discussing=20 how to get this one moving, given we hadn't=20 really had many specific criticisms, so this is very useful - thanks. I'll respond with my personal reactions, and=20 leave my co-author, Matt, to come back on anything. At 15:12 04/06/2013, Mirja K=FChlewind wrote: >Hi, > >sorry for the very late review. The draft reads actually very well. I only >have some high level comments: > >1) The very long title of Figure 1 was kind of confusing me. OK, we need a caption like "The flow of ConEx=20 signals in the context of the pre-existing flows=20 of congestion signals over an end-to-end connection" Then fold the 3-sentence post-amble under the=20 Figure into the body text, where it refers to the Figure. >2) Section 'Overview' is very long (for an overview). Don't know if= per-flow >state, byte vs. packet and partial deployment needs to be discussed here. >Maybe think about a subsection on discussion points instead (which could= also >include some discussion on attacks against the audit). On the other hand >potentially introduce briefly the credit concept here. Flow-state: I'd be happy to move most of the first half of=20 the para into an introductory paragraph under=20 S.5.4. "Policy Devices" about flow-state. That=20 would leave just a high level sentence about the=20 trade-off in the introduction, with a pointer to S.5.4. Something like: " One of the design goals of the ConEx protocol is that the important policy mechanisms can be implemented for heavily aggregated traffic in= the core of the Internet per logical link without=20 per flow state (see Section 5.4). However, the price to pay for avoiding flow state for policy is flow= state to audit ConEx signals, which is discussed further in Section 5.5. In summary: i) flow state for auditing does not require route pinning; ii) auditing at the edges, with limited per flow state, enables policy elsewhere, including in the core, without any per flow state. " >3) Maybe define the term 'congestion signal' in section 2.1 Would the following change to the start of the 2nd para be enough: OLD Networks indicate congestion by three possible signals: packet loss, ECN marking or queueing delay. NEW Networks indicate congestion by three=20 possible congestion signals: packet loss, ECN marking or queueing delay. >4) I'm not sure that section 4.6 is at the right postion as it seems to me >more related to requirements on the encoding. We already have the two requirements sentences=20 from Section 4.6 as items D & E in Section 3.3. Would it fix your concern if, instead of just=20 stating these two requirements, we make the=20 SHOULDs lower case and refer back to the actual SHOULD requirements earlier: OLD Therefore a ConEx encoding SHOULD explicity specify whether it assumes units of bytes or packets for both congestion indications and ConEx markings. [I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications SHOULD be interpreted in units of bytes when responding to congestion, at least on today's Internet. In any TCP implementation this is simple to achieve for varying size packets, given TCP SACK tracks losses in bytes. If an encoding is specified in units of bytes, the encoding SHOULD also specify which headers to include in the size of a packet. NEW This is why a ConEx encoding should explicity specify whether it assumes units of bytes or packets for both congestion indications and ConEx markings (see requirement D in Section 3.3.). [I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion indications SHOULD be interpreted in units of bytes when responding to congestion, at least on today's Internet. In any TCP implementation this is simple to achieve for varying size packets, given TCP SACK tracks losses in bytes. If an encoding is specified in units of bytes, the encoding should also specify which headers to include in the size of a packet (requirement E in Section 3.3). >5) Maybe address briefly how to handle ConEx-not-Marked and not= ConEx-capable >packets (not only for partial deployment but also in regular operation).= They >need to be limited somehow as well, otherwise a sender can easily cheat by >sending ConEx-not-Marked. And this has to be done by the policer (and not= the >audit though). I think you mean solely Not-ConEx. (ConEx-Not-Marked means Conex-enabled but not=20 marked - this highlights that we haven't defined=20 that word well; Section 4.5. defines it with the=20 same meaning as before, but it hasn't been defined before.). There is a para about this in S.6, starting "A=20 network operator can create incentives for=20 senders to voluntarily reveal ConEx information. ..." Nonetheless, that in a bullet about senders, so I=20 would be happy to write something more specific=20 in the section on policy devices, which is where=20 this is more relevant. Also, a very simple=20 sentence under audit, saying it ignores Not-ConEx. >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss >estimation. Perhaps this would be solved by moving Generic=20 loss auditing before the more specific loss=20 auditing bullets, because it basically says=20 generic isn't possible. Then ending generic loss=20 auditing with a linking sentence saying=20 "Nonetheless, loss auditing is possible in the following specific= scenarios." In hindsight, we now have another way of doing=20 generic loss auditing, which I'd like to add. A=20 network can tunnel traffic and turn on ECN in the=20 outer, just for the length of the tunnel. Then,=20 by RFC6040, the tunnel egress will drop any=20 ECN-marked packets with an the inner showing that=20 the e2e transport is Not-ECN-capable. So, an auditor at the tunnel egress will see all=20 the congestion signals from within the network as=20 ECN, then the tunnel egress will transform ECN=20 into drop for those transports that don't support ECN. >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of >credits is well enough specified here. My personal option is that credits >should somehow get invalid (at some point in time). This is left open in= the >current text. I think we need to agree before we can talk about writing down what we= agree... Rather than thinking of Credit expiring after a=20 time, one can think of the combination of recent=20 Re-Echo signals and earlier Credit signals=20 keeping the Credit state fresh within a flow. As=20 long as you've sent Credit before a round of=20 congestion, then if you send Re-Echo after the=20 Auditor can switch it round as if you sent the=20 Re-Echo before and the Credit after. So, when the Auditor holds Credit, it allows up=20 to that amount of Re-Echo to be considered as=20 having been sent before the congestion, rather=20 than after. Then, as it switches the Re-Echoes=20 back in time, it switches the Credits forward, so they always stay recent. Credit is primarily a mechanism to ensure the=20 sender has to suffer some cost before it is=20 trusted to pay back some cost. Credit doesn't=20 need to degrade over time if the cost to the=20 sender of introducing credit doesn't degrade over time. Does this move us forward, or do you still=20 disagree? If so, I suggest a new thread would be useful. >10) In section 6 it is stated that 'Networks MUST NOT change ConEx marked >packets to not_ConEx. [...]'. Maybe move this to the requirement section, >otherwise it might be easily overread. Yes. Thanks. And the same goes for collecting any=20 the other later normative language into the requirements section. >11) Security Considerations lists a number of=20 >attacks. Shouldn't this document >also give hints how to handle these attacks? Especially for the 'Dragging >Down a Spoofed Flow ID', I can't really come up with a good solution...? You're right that this is the hardest known=20 attack to defend against. The draft currently=20 refers to my thesis for two solutions. See Section 7.5.3 of It also includes an analysis of how difficult=20 this attack is for a blind attacker. The attack=20 only works while it sends numerous packets over a=20 5-tuple that matches a target flow. It only has=20 to scan the most fruiful parts of the 5-tuple=20 space, but it can't detect when it has hit a=20 match, so it has to send large numbers of packets=20 over each 5-tuple just in case. BTW, the attack=20 is trivial for a man-in-the-middle, but he can drop everything anyway. I have promised to transcribe that material into=20 the RFC series eventually, but it's not a=20 priority before we get experimental use of ConEx.=20 I believe it's OK at this stage as long as the=20 solutions are documented /somewhere/ and referred to. Is that acceptable? Thanks v much for this full review. We needed this. Bob >Mirja ________________________________________________________________ Bob Briscoe, BT=20 From mattmathis@google.com Wed Jun 5 23:02:11 2013 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 3CBF621F8952 for ; Wed, 5 Jun 2013 23:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+IkgONCD0Gk for ; Wed, 5 Jun 2013 23:02:09 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27821F8808 for ; Wed, 5 Jun 2013 23:02:08 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id at1so2094703iec.37 for ; Wed, 05 Jun 2013 23:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YYnHuMdLEmo1UA8kkezolUnrBSmQzwUkxDCs99I1w1o=; b=OUXQqY59ClxeWIEwxCkmWHlmrkqLtvPXgG3fIA35CYSk04BLssOYoR2w0UWsMWktYT VFgq6kKNrYqFOxSdvas/Ix5Bl8adETgfo1HzK3ASjGQ18yn0Q4PzZDiUmhC7qZ4P53qt GwignuRATQ4AyWqUbm9V+lY9hFuKc0GFIZObeRfv8ikOI13jiuZtIMnp4k+tcUzlW2Mm 3oD84qQK10fvPegB8HesHkwiVmbofvfactyVrMBz8Yk4HdCUG2F/dDOSyqWve3iFAbu+ 4QpNXUuG+pQ1jKmh7grQhN0wtVG3739kDXRHLKVbbPcb62BnRn/kl0OwOxu/3ue18Sow XjVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YYnHuMdLEmo1UA8kkezolUnrBSmQzwUkxDCs99I1w1o=; b=UrGQByfJ1eJPX+9NjIj/4cXmJRYb9/NfAseY4KnGUwHy/HWV+9K/F8BplaErQaI4s+ wR9lrWWrFpyMW5kT9pi80oZLFkn8OqsI6Ww6weFPYqVxhGYnMoYM61Ja5YkjLfax9mHi WJvdsVGmuO2+uMvcJNUEB//PuG5FL+mKm9NRIbx2uXUwxb+f20EqbxJFTh9ei0zB9NPE jtWRpaGEtH3XB5wCa5rmR73NuSDZyC2zdo0Lpj2ws3QxekLJGJAgqZcz078aQXzq0As2 FJMFqtIHbM6ZbJlFc8YKAspXtnAwgRNA6599k331RyS61CxQRwN/+GL86jdkApsnzkJQ zIvg== MIME-Version: 1.0 X-Received: by 10.50.56.11 with SMTP id w11mr5031012igp.50.1370498526610; Wed, 05 Jun 2013 23:02:06 -0700 (PDT) Received: by 10.64.91.163 with HTTP; Wed, 5 Jun 2013 23:02:06 -0700 (PDT) In-Reply-To: <201306041912.r54JCmTJ012702@bagheera.jungle.bt.co.uk> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306041912.r54JCmTJ012702@bagheera.jungle.bt.co.uk> Date: Wed, 5 Jun 2013 23:02:06 -0700 Message-ID: From: Matt Mathis To: Bob Briscoe Content-Type: multipart/alternative; boundary=089e01537cf8d894e204de760dfe X-Gm-Message-State: ALoCoQmaNNviqmEIHmnarx8UqwMS3vliGqmK9lcCpsIJpQOZTW2fRNLWzab7i1X2KNMldNygVgBwa3Ut3XBepV0FOd2RzOzS5jg+nSHEL3yJm18zBQnByHLjFmBm1aclTjiT17IzIASiHEZ3+UhSBdlNu1cH/jleVhrZvqA1Svf5IM/48IN6aelRpP3zZvLB204M832gQMaw Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Thu, 06 Jun 2013 06:02:11 -0000 --089e01537cf8d894e204de760dfe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Follow up to Mirja's and Bob's comments, inline. most are "Looks Good to Me". On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe wrote: > At 15:12 04/06/2013, Mirja K=FChlewind wrote: > >> >> 1) The very long title of Figure 1 was kind of confusing me. >> > > OK, we need a caption like "The flow of ConEx signals in the context of > the pre-existing flows of congestion signals over an end-to-end connectio= n" > > Then fold the 3-sentence post-amble under the Figure into the body text, > where it refers to the Figure. > This is supposed to be a caption (not a title), but yes the RFC formatting is confusing. I would suggest something even simpler "The flow of congestion and ConEx signals." and move the rest into the running text. > > 2) Section 'Overview' is very long (for an overview). Don't know if >> per-flow >> state, byte vs. packet and partial deployment needs to be discussed here= . >> Maybe think about a subsection on discussion points instead (which could >> also >> include some discussion on attacks against the audit). On the other hand >> potentially introduce briefly the credit concept here. >> > > Flow-state: > I'd be happy to move most of the first half of the para into an > introductory paragraph under S.5.4. "Policy Devices" about flow-state. Th= at > would leave just a high level sentence about the trade-off in the > introduction, with a pointer to S.5.4. Something like: > > " One of the design goals of the ConEx protocol is that the important > policy mechanisms can be implemented for heavily aggregated traffic in > the > core of the Internet per logical link without per flow state (see > Section 5.4). > However, the price to pay for avoiding flow state for policy is flow > state > to audit ConEx signals, which is discussed further in Section 5.5. In > summary: i) flow state for auditing does not require route pinning; > ii) auditing at the edges, with limited per flow state, enables > policy elsewhere, including in the core, without any per flow state. > > " > I would make the 2nd part even simpler "A suitable auditing design enables policy elsewhere, including the core, without any per flow state". > > 3) Maybe define the term 'congestion signal' in section 2.1 >> > > Would the following change to the start of the 2nd para be enough: > > OLD > Networks indicate congestion by three possible signals: packet loss, > ECN marking or queueing delay. > NEW > Networks indicate congestion by three possible congestion signals: > packet loss, > ECN marking or queueing delay. > LGTM > > 4) I'm not sure that section 4.6 is at the right postion as it seems to = me >> more related to requirements on the encoding. >> > > We already have the two requirements sentences from Section 4.6 as items = D > & E in Section 3.3. > > Would it fix your concern if, instead of just stating these two > requirements, we make the SHOULDs lower case and refer back to the actual > SHOULD requirements earlier: > > OLD > Therefore a ConEx encoding SHOULD explicity specify whether it > assumes units of bytes or packets for both congestion indications and > ConEx markings. > > [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion indication= s > SHOULD be interpreted in units of bytes when responding to > congestion, at least on today's Internet. In any TCP implementation > this is simple to achieve for varying size packets, given TCP SACK > tracks losses in bytes. If an encoding is specified in units of > bytes, the encoding SHOULD also specify which headers to include in > the size of a packet. > NEW > This is why a ConEx encoding should explicity specify whether it > assumes units of bytes or packets for both congestion indications and > ConEx markings (see requirement D in Section 3.3.). > > [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion indication= s > SHOULD be interpreted in units of bytes when responding to > congestion, at least on today's Internet. In any TCP implementation > this is simple to achieve for varying size packets, given TCP SACK > tracks losses in bytes. If an encoding is specified in units of > bytes, the encoding should also specify which headers to include in > the size of a packet (requirement E in Section 3.3). > LGTM > 5) Maybe address briefly how to handle ConEx-not-Marked and not >> ConEx-capable >> packets (not only for partial deployment but also in regular operation). >> They >> need to be limited somehow as well, otherwise a sender can easily cheat = by >> sending ConEx-not-Marked. And this has to be done by the policer (and no= t >> the >> audit though). >> > > I think you mean solely Not-ConEx. > (ConEx-Not-Marked means Conex-enabled but not marked - this highlights > that we haven't defined that word well; Section 4.5. defines it with the > same meaning as before, but it hasn't been defined before.). > > There is a para about this in S.6, starting "A network operator can creat= e > incentives for senders to voluntarily reveal ConEx information. ..." > > Nonetheless, that in a bullet about senders, so I would be happy to write > something more specific in the section on policy devices, which is where > this is more relevant. Also, a very simple sentence under audit, saying i= t > ignores Not-ConEx. > I want to think about this one more: propose something more specific. 8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss > estimation. >> > Today essentially all encryption is above TCP, because IPsec does not play nice with NATs, and I can't see that changing. Furthermore there is already quite a menagerie of FW class devices that refuse non-TCP and TCP with nonsensical sequence numbers (to thwart various injection attacks). We already encrypt nearly all of our payload, except some services and some countries. It feels like this is important from pedantic completeness standpoint but not much of an issue in the real world. Let me think about this before you reorganize the section. Perhaps this would be solved by moving Generic loss auditing before the > more specific loss auditing bullets, because it basically says generic > isn't possible. Then ending generic loss auditing with a linking sentence > saying "Nonetheless, loss auditing is possible in the following specific > scenarios." > > In hindsight, we now have another way of doing generic loss auditing, > which I'd like to add. A network can tunnel traffic and turn on ECN in th= e > outer, just for the length of the tunnel. Then, by RFC6040, the tunnel > egress will drop any ECN-marked packets with an the inner showing that th= e > e2e transport is Not-ECN-capable. > > So, an auditor at the tunnel egress will see all the congestion signals > from within the network as ECN, then the tunnel egress will transform ECN > into drop for those transports that don't support ECN. > This isn't really audit is it? What happens if a transport says it can do ECN, but just ignores it? 9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of > credits is well enough specified here. My personal option is that credits >> should somehow get invalid (at some point in time). This is left open in >> the >> current text. >> > > I think we need to agree before we can talk about writing down what we > agree... > I think that abstract-mech needs to embrace *both*, explicitly if not implicitly. I need to think about this some more, but I suspect that it means we have unnecessarily over constrained audit here. > Rather than thinking of Credit expiring after a time, one can think of th= e > combination of recent Re-Echo signals and earlier Credit signals keeping > the Credit state fresh within a flow. As long as you've sent Credit befor= e > a round of congestion, then if you send Re-Echo after the Auditor can > switch it round as if you sent the Re-Echo before and the Credit after. > > So, when the Auditor holds Credit, it allows up to that amount of Re-Echo > to be considered as having been sent before the congestion, rather than > after. Then, as it switches the Re-Echoes back in time, it switches the > Credits forward, so they always stay recent. > > Credit is primarily a mechanism to ensure the sender has to suffer some > cost before it is trusted to pay back some cost. Credit doesn't need to > degrade over time if the cost to the sender of introducing credit doesn't > degrade over time. > > Does this move us forward, or do you still disagree? If so, I suggest a > new thread would be useful. > This is probably correct, but I really don't think it belongs in A-M. > 10) In section 6 it is stated that 'Networks MUST NOT change ConEx marke= d >> packets to not_ConEx. [...]'. Maybe move this to the requirement section= , >> otherwise it might be easily overread. >> > > Yes. Thanks. And the same goes for collecting any the other later > normative language into the requirements section. > Yep, I agreee > > > > 11) Security Considerations lists a number of attacks. Shouldn't this >> document >> also give hints how to handle these attacks? Especially for the 'Draggin= g >> Down a Spoofed Flow ID', I can't really come up with a good solution...? >> > > You're right that this is the hardest known attack to defend against. The > draft currently refers to my thesis for two solutions. See Section 7.5.3 = of > > > > It also includes an analysis of how difficult this attack is for a blind > attacker. The attack only works while it sends numerous packets over a > 5-tuple that matches a target flow. It only has to scan the most fruiful > parts of the 5-tuple space, but it can't detect when it has hit a match, = so > it has to send large numbers of packets over each 5-tuple just in case. > BTW, the attack is trivial for a man-in-the-middle, but he can drop > everything anyway. > > I have promised to transcribe that material into the RFC series > eventually, but it's not a priority before we get experimental use of > ConEx. I believe it's OK at this stage as long as the solutions are > documented /somewhere/ and referred to. > > Is that acceptable? > LGTM > > Thanks v much for this full review. We needed this. > Except for the couple of items for more thought, dig in! Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. --089e01537cf8d894e204de760dfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Follow up to Mirja's and Bo= b's comments, inline. =A0 most are "Looks Good to Me".
<= div class=3D"gmail_extra">

On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe <= bob.briscoe@bt.com> wrote:
At 15:12 04/06= /2013, Mirja K=FChlewind wrote:

1) The very long title of Figure 1 was kind of confusing me.

OK, we need a caption like "The flow of ConEx signals in the context o= f the pre-existing flows of congestion signals over an end-to-end connectio= n"

Then fold the 3-sentence post-amble under the Figure into the body text, wh= ere it refers to the Figure.
This is supposed = to be a caption (not a title), but yes the RFC formatting is confusing. =A0= I would suggest something even simpler "The flow of congestion and Co= nEx signals." =A0and move the rest into the running text.
<= div class=3D"im">
2) Section 'Overview' is very long (for an overview). Don't kno= w if per-flow
state, byte vs. packet and partial deployment needs to be discussed here. Maybe think about a subsection on discussion points instead (which could al= so
include some discussion on attacks against the audit). On the other hand potentially introduce briefly the credit concept here.

Flow-state:
I'd be happy to move most of the first half of the para into an introdu= ctory paragraph under S.5.4. "Policy Devices" about flow-state. T= hat would leave just a high level sentence about the trade-off in the intro= duction, with a pointer to S.5.4. Something like:

" =A0One of the design goals of the ConEx protocol is that the importa= nt
=A0 =A0policy mechanisms can be implemented for heavily aggregated traffic = in the
=A0 =A0core of the Internet per logical link without per flow state (see Se= ction 5.4).
=A0 =A0However, the price to pay for avoiding flow state for policy is flow= state
=A0 =A0to audit ConEx signals, which is discussed further in Section 5.5. = =A0In
=A0 =A0summary: i) flow state for auditing does not require route pinning;<= br> =A0 =A0ii) auditing at the edges, with limited per flow state, enables
=A0 =A0policy elsewhere, including in the core, without any per flow state.=

"

I would make the 2nd part even simpler =A0"A suitable auditing= design enables policy elsewhere, including the core, without any per flow = state".
=A0

3) Maybe define the term 'congestion signal' in section 2.1

Would the following change to the start of the 2nd para be enough:

OLD
=A0 =A0Networks indicate congestion by three possible signals: packet loss,=
=A0 =A0ECN marking or queueing delay.
NEW
=A0 =A0Networks indicate congestion by three possible congestion signals: p= acket loss,
=A0 =A0ECN marking or queueing delay.

LGTM

4) I'm not sure that section 4.6 is at the right postion as it seems to= me
more related to requirements on the encoding.

We already have the two requirements sentences from Section 4.6 as items D = & E in Section 3.3.

Would it fix your concern if, instead of just stating these two requirement= s, we make the SHOULDs lower case and refer back to the actual SHOULD requi= rements earlier:

OLD
=A0 =A0Therefore a ConEx encoding SHOULD explicity specify whether it
=A0 =A0assumes units of bytes or packets for both congestion indications an= d
=A0 =A0ConEx markings.

=A0 =A0[I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion ind= ications
=A0 =A0SHOULD be interpreted in units of bytes when responding to
=A0 =A0congestion, at least on today's Internet. =A0In any TCP implemen= tation
=A0 =A0this is simple to achieve for varying size packets, given TCP SACK =A0 =A0tracks losses in bytes. =A0If an encoding is specified in units of =A0 =A0bytes, the encoding SHOULD also specify which headers to include in<= br> =A0 =A0the size of a packet.
NEW
=A0 =A0This is why a ConEx encoding should explicity specify whether it
=A0 =A0assumes units of bytes or packets for both congestion indications an= d
=A0 =A0ConEx markings (see requirement D in Section 3.3.).

=A0 =A0[I-D.ietf-tsvwg-byte-pkt-congest] advises that congestion ind= ications
=A0 =A0SHOULD be interpreted in units of bytes when responding to
=A0 =A0congestion, at least on today's Internet. =A0In any TCP implemen= tation
=A0 =A0this is simple to achieve for varying size packets, given TCP SACK =A0 =A0tracks losses in bytes. =A0If an encoding is specified in units of =A0 =A0bytes, the encoding should also specify which headers to include in<= br> =A0 =A0the size of a packet (requirement E in Section 3.3).

LGTM
=A0
5) Maybe address briefly how to handle ConEx-not-Marked and not ConEx-capab= le
packets (not only for partial deployment but also in regular operation). Th= ey
need to be limited somehow as well, otherwise a sender can easily cheat by<= br> sending ConEx-not-Marked. And this has to be done by the policer (and not t= he
audit though).

I think you mean solely Not-ConEx.
(ConEx-Not-Marked means Conex-enabled but not marked - this highlights that= we haven't defined that word well; Section 4.5. defines it with the sa= me meaning as before, but it hasn't been defined before.).

There is a para about this in S.6, starting "A network operator can cr= eate incentives for senders to voluntarily reveal ConEx information. ...&qu= ot;

Nonetheless, that in a bullet about senders, so I would be happy to write s= omething more specific in the section on policy devices, which is where thi= s is more relevant. Also, a very simple sentence under audit, saying it ign= ores Not-ConEx.
=A0
=A0I want to think about this one mor= e: propose something more specific.
=A0
8) Section 5.5 doesn't give any advise how to handl= e encrypted TCP for loss
<= div class=3D"im">
estimation.

Today essentially all encryption is above TCP, because IPsec does not p= lay nice with NATs, and I can't see that changing. =A0 =A0Furthermore t= here is already quite a menagerie of FW class devices that refuse non-TCP a= nd TCP with nonsensical sequence numbers (to thwart various injection attac= ks). =A0We already encrypt nearly all of our payload, except some services = and some countries.=A0

It feels like this is important from pedant= ic completeness standpoint but not much of an issue in the real world.

Let me think about this before you reorgan= ize the section.

Perhaps this would be solved by moving Generic loss auditing before the mor= e specific loss auditing bullets, because it basically says generic isn'= ;t possible. Then ending generic loss auditing with a linking sentence sayi= ng "Nonetheless, loss auditing is possible in the following specific s= cenarios."

In hindsight, we now have another way of doing generic loss auditing, which= I'd like to add. A network can tunnel traffic and turn on ECN in the o= uter, just for the length of the tunnel. Then, by RFC6040, the tunnel egres= s will drop any ECN-marked packets with an the inner showing that the e2e t= ransport is Not-ECN-capable.

So, an auditor at the tunnel egress will see all the congestion signals fro= m within the network as ECN, then the tunnel egress will transform ECN into= drop for those transports that don't support ECN.

This isn't really audit is it? =A0What happen= s if a transport says it can do ECN, but just ignores it?
=A0
9) Section 5.5.1 introdues the cr= edit concept. Not sure if the meaning of
<= div class=3D"im">
credits is well enough specified here. My personal option is that credits should somehow get invalid (at some point in time). This is left open in th= e
current text.

I think we need to agree before we can talk about writing down what we agre= e...

I think that abstract-= mech needs to embrace *both*, explicitly if not implicitly. =A0I need to th= ink about this some more, but I suspect that it means we have unnecessarily= over constrained audit here.=A0


Rather than thinking of Credit expiring after a time, one can think of the = combination of recent Re-Echo signals and earlier Credit signals keeping th= e Credit state fresh within a flow. As long as you've sent Credit befor= e a round of congestion, then if you send Re-Echo after the Auditor can swi= tch it round as if you sent the Re-Echo before and the Credit after.

So, when the Auditor holds Credit, it allows up to that amount of Re-Echo t= o be considered as having been sent before the congestion, rather than afte= r. Then, as it switches the Re-Echoes back in time, it switches the Credits= forward, so they always stay recent.

Credit is primarily a mechanism to ensure the sender has to suffer some cos= t before it is trusted to pay back some cost. Credit doesn't need to de= grade over time if the cost to the sender of introducing credit doesn't= degrade over time.

Does this move us forward, or do you still disagree? If so, I suggest a new= thread would be useful.

This i= s probably correct, but I really don't think it belongs in A-M.
=A0
10) In section 6 it is stated that 'Networks MUST NOT change ConEx mark= ed
packets to not_ConEx. [...]'. Maybe move this to the requirement sectio= n,
otherwise it might be easily overread.

Yes. Thanks. And the same goes for collecting any the other later normative= language into the requirements section.

<= div style>Yep, I agreee=A0



11) Security Considerations lists a number of attacks. Shouldn't this d= ocument
also give hints how to handle these attacks? Especially for the 'Draggi= ng
Down a Spoofed Flow ID', I can't really come up with a good solutio= n...?

You're right that this is the hardest known attack to defend against. T= he draft currently refers to my thesis for two solutions. See Section 7.5.3= of
<http://bobbriscoe.net/projects/refb/#refb-dis>
It also includes an analysis of how difficult this attack is for a blind at= tacker. The attack only works while it sends numerous packets over a 5-tupl= e that matches a target flow. It only has to scan the most fruiful parts of= the 5-tuple space, but it can't detect when it has hit a match, so it = has to send large numbers of packets over each 5-tuple just in case. BTW, t= he attack is trivial for a man-in-the-middle, but he can drop everything an= yway.

I have promised to transcribe that material into the RFC series eventually,= but it's not a priority before we get experimental use of ConEx. I bel= ieve it's OK at this stage as long as the solutions are documented /som= ewhere/ and referred to.

Is that acceptable?

LGTM=A0=

Thanks v much for this full review. We needed this.
<= /div>
Except for the couple of items for more thought, dig in!

Thanks,
--MM--
The best way = to predict the future is to create it. =A0- Alan Kay

Privacy matters! =A0We know from recent events that people are using ou= r services to speak in defiance of unjust governments. =A0 We treat privacy= and security as matters of life and death, because for some users, they ar= e.
--089e01537cf8d894e204de760dfe-- From bob.briscoe@bt.com Thu Jun 6 16:59:30 2013 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 ADC0B21F8904 for ; Thu, 6 Jun 2013 16:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mvm-S9tNHqM for ; Thu, 6 Jun 2013 16:59:24 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63821F8900 for ; Thu, 6 Jun 2013 16:59:22 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 7 Jun 2013 00:59:20 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 7 Jun 2013 00:59:19 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Fri, 7 Jun 2013 00:59:18 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.112.140]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r56NxFrm020485; Fri, 7 Jun 2013 00:59:15 +0100 Message-ID: <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 7 Jun 2013 00:57:26 +0100 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306041912.r54JCmTJ012702@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_540902937==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Thu, 06 Jun 2013 23:59:30 -0000 --=====================_540902937==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Matt, A few rejoinders inline... At 07:02 06/06/2013, Matt Mathis wrote: >Follow up to Mirja's and Bob's comments,=20 >inline. most are "Looks Good to Me". > > >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe=20 ><bob.briscoe@bt.com> wrote: >At 15:12 04/06/2013, Mirja K=FChlewind wrote: [snip] >2) Section 'Overview' is very long (for an overview). Don't know if= per-flow >state, byte vs. packet and partial deployment needs to be discussed here. >Maybe think about a subsection on discussion points instead (which could= also >include some discussion on attacks against the audit). On the other hand >potentially introduce briefly the credit concept here. > > >Flow-state: >I'd be happy to move most of the first half of=20 >the para into an introductory paragraph under=20 >S.5.4. "Policy Devices" about flow-state. That=20 >would leave just a high level sentence about the=20 >trade-off in the introduction, with a pointer to S.5.4. Something like: > >" One of the design goals of the ConEx protocol is that the important > policy mechanisms can be implemented for heavily aggregated traffic in= the > core of the Internet per logical link=20 > without per flow state (see Section 5.4). > However, the price to pay for avoiding flow state for policy is flow= state > to audit ConEx signals, which is discussed further in Section 5.5. In > summary: i) flow state for auditing does not require route pinning; > ii) auditing at the edges, with limited per flow state, enables > policy elsewhere, including in the core, without any per flow state. > >" > > >I would make the 2nd part even simpler "A=20 >suitable auditing design enables policy=20 >elsewhere, including the core, without any per flow state". [BB]: Not sure where you intend 'the 2nd part' to=20 start. I'd like some residual hint left in the=20 Intro that we don't need route pinning. How about: " One of the design goals of the ConEx protocol is that the important policy mechanisms can be implemented for heavily aggregated traffic in= the core of the Internet per logical link without=20 per flow state (see Section 5.4). However, the price to pay for avoiding flow state for policy is flow= state to audit ConEx signals, which is discussed further in Section 5.5. In summary, a suitable edge-based auditing=20 design using soft per-flow state enables policy elsewhere, including the core, without any per flow state. " Also, I forgot to address Mirja's request to move=20 most of the byte-pkt text from the Intro into the=20 body. I pushed for that before, so I'll leave you=20 to argue if you don't agree. While, if you do=20 agree, you can suggest what to leave, and what to move. > 5) Maybe address briefly how to handle=20 > ConEx-not-Marked and not ConEx-capable >packets (not only for partial deployment but also in regular operation).= They >need to be limited somehow as well, otherwise a sender can easily cheat by >sending ConEx-not-Marked. And this has to be done by the policer (and not= the >audit though). > > >I think you mean solely Not-ConEx. >(ConEx-Not-Marked means Conex-enabled but not=20 >marked - this highlights that we haven't defined=20 >that word well; Section 4.5. defines it with the=20 >same meaning as before, but it hasn't been defined before.). > >There is a para about this in S.6, starting "A=20 >network operator can create incentives for=20 >senders to voluntarily reveal ConEx information. ..." > >Nonetheless, that in a bullet about senders, so=20 >I would be happy to write something more=20 >specific in the section on policy devices, which=20 >is where this is more relevant. Also, a very=20 >simple sentence under audit, saying it ignores Not-ConEx. > > > I want to think about this one more: propose something more specific. > >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss >estimation. > > >Today essentially all encryption is above TCP,=20 >because IPsec does not play nice with NATs, and=20 >I can't see that changing. Furthermore there=20 >is already quite a menagerie of FW class devices=20 >that refuse non-TCP and TCP with nonsensical=20 >sequence numbers (to thwart various injection=20 >attacks). We already encrypt nearly all of our=20 >payload, except some services and some countries. > >It feels like this is important from pedantic=20 >completeness standpoint but not much of an issue in the real world. [BB]: Mirja's point was we don't say what can (or=20 cannot) be done with encrypted TCP. I don't think=20 she's looking for an evasive answer like "There=20 probably isn't much encrypted TCP". I don't=20 believe we should base protocol design on=20 predictions of the future traffic mix. We should=20 make the admission clear that we can't do=20 anything with encrypted TCP (and similarly multipath is tough). >Let me think about this before you reorganize the section. > >Perhaps this would be solved by moving Generic=20 >loss auditing before the more specific loss=20 >auditing bullets, because it basically says=20 >generic isn't possible. Then ending generic loss=20 >auditing with a linking sentence saying=20 >"Nonetheless, loss auditing is possible in the following specific= scenarios." > >In hindsight, we now have another way of doing=20 >generic loss auditing, which I'd like to add. A=20 >network can tunnel traffic and turn on ECN in=20 >the outer, just for the length of the tunnel.=20 >Then, by RFC6040, the tunnel egress will drop=20 >any ECN-marked packets with an the inner showing=20 >that the e2e transport is Not-ECN-capable. > >So, an auditor at the tunnel egress will see all=20 >the congestion signals from within the network=20 >as ECN, then the tunnel egress will transform=20 >ECN into drop for those transports that don't support ECN. > > >This isn't really audit is it? What happens if=20 >a transport says it can do ECN, but just ignores it? [BB]: Audit checks whether the transport receiver=20 and/or sender expose the congestion they see=20 (then policy devices can rely on this exposed=20 info to police anyone ignoring congestion - if that's the policy). The tunnel turns on ECN support in the outer to=20 ensure any congestion at intermediate nodes can=20 all be exposed to the auditor as ECN marks not=20 losses. It works for all packets (even DNS),=20 whatever the e2e transport says about ECN support (in the inner). Nonetheless, for those transports that say they=20 don't support ECN, the tunnel egress converts all=20 congestion signals into drops (after the auditor=20 has read the ECN signals). This 'just works' if=20 the tunnel complies with RFC6040. > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of >credits is well enough specified here. My personal option is that credits >should somehow get invalid (at some point in time). This is left open in= the >current text. > > >I think we need to agree before we can talk=20 >about writing down what we agree... > > >I think that abstract-mech needs to embrace=20 >*both*, explicitly if not implicitly. I need to=20 >think about this some more, but I suspect that=20 >it means we have unnecessarily over constrained audit here. [BB]: We need to allow multiple experiments at=20 this experimental stage. But ultimately, sources=20 will need to unambiuously know what Credit means,=20 so they know how much to introduce and when. >Rather than thinking of Credit expiring after a=20 >time, one can think of the combination of recent=20 >Re-Echo signals and earlier Credit signals=20 >keeping the Credit state fresh within a flow. As=20 >long as you've sent Credit before a round of=20 >congestion, then if you send Re-Echo afterwards=20 >the Auditor can switch it round as if you sent=20 >the Re-Echo before and the Credit after. > >So, when the Auditor holds Credit, it allows up=20 >to that amount of Re-Echo to be considered as=20 >having been sent before the congestion, rather=20 >than after. Then, as it switches the Re-Echoes=20 >back in time, it switches the Credits forward, so they always stay recent. > >Credit is primarily a mechanism to ensure the=20 >sender has to suffer some cost before it is=20 >trusted to pay back some cost. Credit doesn't=20 >need to degrade over time if the cost to the=20 >sender of introducing credit doesn't degrade over time. > >Does this move us forward, or do you still=20 >disagree? If so, I suggest a new thread would be useful. > > >This is probably correct, but I really don't think it belongs in A-M. [BB]: I don't think it should either. This is a=20 discussion with Mirja, rather than a proposal for text. > >Except for the couple of items for more thought, dig in! Looking forward to the rest. CHeers Bob >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > >Privacy matters! We know from recent events=20 >that people are using our services to speak in=20 >defiance of unjust governments. We treat=20 >privacy and security as matters of life and=20 >death, because for some users, they are. ________________________________________________________________ Bob Briscoe, BT=20 --=====================_540902937==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt,

A few rejoinders inline...

At 07:02 06/06/2013, Matt Mathis wrote:
Follow up to Mirja's and Bob'= s comments, inline.   most are "Looks Good to Me".


On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe <bob.briscoe@bt.com> wrote:
At 15:12 04/06/2013, Mirja K=FChlewind wrote:

[snip]

2) Section 'Overview' is very long (for an overview). Don't know if per-flow
state, byte vs. packet and partial deployment needs to be discussed here.
Maybe think about a subsection on discussion points instead (which could also
include some discussion on attacks against the audit). On the other hand
potentially introduce briefly the credit concept here.


Flow-state:
I'd be happy to move most of the first half of the para into an introductory paragraph under S.5.4. "Policy Devices" about flow-state. That would leave just a high level sentence about the trade-off in the introduction, with a pointer to S.5.4. Something like:

"  One of the design goals of the ConEx protocol is that the important
   policy mechanisms can be implemented for heavily aggregated traffic in the
   core of the Internet per logical link without per flow state (see Section 5.4).
   However, the price to pay for avoiding flow state for policy is flow state
   to audit ConEx signals, which is discussed further in Section 5.5.  In
   summary: i) flow state for auditing does not require route pinning;
   ii) auditing at the edges, with limited per flow state, enables
   policy elsewhere, including in the core, without any per flow state.

"


I would make the 2nd part even simpler  "A suitable auditing design enables policy elsewhere, including the core, without any per flow state".

[BB]: Not sure where you intend 'the 2nd part' to start. I'd like some residual hint left in the Intro that we don't need route pinning. How about:

"  One of the design goals of the ConEx protocol is that the important
   policy mechanisms can be implemented for heavily aggregated traffic in the
   core of the Internet per logical link without per flow state (see Section 5.4).
   However, the price to pay for avoiding flow state for policy is flow state
   to audit ConEx signals, which is discussed further in Section 5.5.  In
   summary, a suitable edge-based auditing design using soft per-flow state enables
   policy elsewhere, including the core, without any per flow state.
"

Also, I forgot to address Mirja's request to move most of the byte-pkt text from the Intro into the body. I pushed for that before, so I'll leave you to argue if you don't agree. While, if you do agree, you can suggest what to leave, and what to move.

 5) Maybe address briefl= y how to handle ConEx-not-Marked and not ConEx-capable
packets (not only for partial deployment but also in regular operation). They
need to be limited somehow as well, otherwise a sender can easily cheat by
sending ConEx-not-Marked. And this has to be done by the policer (and not the
audit though).


I think you mean solely Not-ConEx.
(ConEx-Not-Marked means Conex-enabled but not marked - this highlights that we haven't defined that word well; Section 4.5. defines it with the same meaning as before, but it hasn't been defined before.).

There is a para about this in S.6, starting "A network operator can create incentives for senders to voluntarily reveal ConEx information. ..."

Nonetheless, that in a bullet about senders, so I would be happy to write something more specific in the section on policy devices, which is where this is more relevant. Also, a very simple sentence under audit, saying it ignores Not-ConEx.

 
 I want to think about this one more: propose something more specific.
 
8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss
estimation.


Today essentially all encryption is above TCP, because IPsec does not play nice with NATs, and I can't see that changing.    Furthermore there is already quite a menagerie of FW class devices that refuse non-TCP and TCP with nonsensical sequence numbers (to thwart various injection attacks).  We already encrypt nearly all of our payload, except some services and some countries.

It feels like this is important from pedantic completeness standpoint but not much of an issue in the real world.

[BB]: Mirja's point was we don't say what can (or cannot) be done with encrypted TCP. I don't think she's looking for an evasive answer like "There probably isn't much encrypted TCP". I don't believe we should base protocol design on predictions of the future traffic mix. We should make the admission clear that we can't do anything with encrypted TCP (and similarly multipath is tough).


Let me think about this befor= e you reorganize the section.

Perhaps this would be solved by moving Generic loss auditing before the more specific loss auditing bullets, because it basically says generic isn't possible. Then ending generic loss auditing with a linking sentence saying "Nonetheless, loss auditing is possible in the following specific scenarios."

In hindsight, we now have another way of doing generic loss auditing, which I'd like to add. A network can tunnel traffic and turn on ECN in the outer, just for the length of the tunnel. Then, by RFC6040, the tunnel egress will drop any ECN-marked packets with an the inner showing that the e2e transport is Not-ECN-capable.

So, an auditor at the tunnel egress will see all the congestion signals from within the network as ECN, then the tunnel egress will transform ECN into drop for those transports that don't support ECN.


This isn't really audit is it?  What happens if a transport says it can do ECN, but just ignores it?

[BB]: Audit checks whether the transport receiver and/or sender expose the congestion they see (then policy devices can rely on this exposed info to police anyone ignoring congestion - if that's the policy).

The tunnel turns on ECN support in the outer to ensure any congestion at intermediate nodes can all be exposed to the auditor as ECN marks not losses. It works for all packets (even DNS), whatever the e2e transport says about ECN support (in the inner).

Nonetheless, for those transports that say they don't support ECN, the tunnel egress converts all congestion signals into drops (after the auditor has read the ECN signals). This 'just works' if the tunnel complies with RFC6040.

 
9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of
credits is well enough specified here. My personal option is that credits
should somehow get invalid (at some point in time). This is left open in the
current text.


I think we need to agree before we can talk about writing down what we agree...


I think that abstract-mech needs to embrace *both*, explicitly if not implicitly.  I need to think about this some more, but I suspect that it means we have unnecessarily over constrained audit here.

[BB]: We need to allow multiple experiments at this experimental stage. But ultimately, sources will need to unambiuously know what Credit means, so they know how much to introduce and when.



Rather than thinking of Credit expiring after a time, one can think of the combination of recent Re-Echo signals and earlier Credit signals keeping the Credit state fresh within a flow. As long as you've sent Credit before a round of congestion, then if you send Re-Echo afterwards the Auditor can switch it round as if you sent the Re-Echo before and the Credit after.

So, when the Auditor holds Credit, it allows up to that amount of Re-Echo to be considered as having been sent before the congestion, rather than after. Then, as it switches the Re-Echoes back in time, it switches the Credits forward, so they always stay recent.

Credit is primarily a mechanism to ensure the sender has to suffer some cost before it is trusted to pay back some cost. Credit doesn't need to degrade over time if the cost to the sender of introducing credit doesn't degrade over time.

Does this move us forward, or do you still disagree? If so, I suggest a new thread would be useful.


This is probably correct, but I really don't think it belongs in A-M.

[BB]: I don't think it should either. This is a discussion with Mirja, rather than a proposal for text.

 
Except for the couple of items for more thought, dig in!

Looking forward to the rest.

CHeers


Bob


Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_540902937==.ALT-- From mirja.kuehlewind@ikr.uni-stuttgart.de Sun Jun 9 07:34:27 2013 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 49E6821F8CDD for ; Sun, 9 Jun 2013 07:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuvjyeM89KwF for ; Sun, 9 Jun 2013 07:34:23 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D584D21F8B04 for ; Sun, 9 Jun 2013 07:34:22 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D5DD860280; Sun, 9 Jun 2013 16:34:19 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A466C6027E; Sun, 9 Jun 2013 16:34:19 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe Date: Sun, 9 Jun 2013 16:34:19 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> In-Reply-To: <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Sun, 09 Jun 2013 14:34:27 -0000 Hi Bob, hi Matt, see inline.... On Friday 07 June 2013 01:57:26 Bob Briscoe wrote: > Matt, > > A few rejoinders inline... > > At 07:02 06/06/2013, Matt Mathis wrote: > >Follow up to Mirja's and Bob's comments, > >inline. most are "Looks Good to Me". > > > > > >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe > ><bob.briscoe@bt.com> wrote: > >At 15:12 04/06/2013, Mirja K=FChlewind wrote: > > [snip] > > >2) Section 'Overview' is very long (for an overview). Don't know if > > per-flow state, byte vs. packet and partial deployment needs to be > > discussed here. Maybe think about a subsection on discussion points > > instead (which could also include some discussion on attacks against the > > audit). On the other hand potentially introduce briefly the credit > > concept here. > > > > > >Flow-state: > >I'd be happy to move most of the first half of > >the para into an introductory paragraph under > >S.5.4. "Policy Devices" about flow-state. That > >would leave just a high level sentence about the > >trade-off in the introduction, with a pointer to S.5.4. Something like: > > > >" One of the design goals of the ConEx protocol is that the important > > policy mechanisms can be implemented for heavily aggregated traffic = in > > the core of the Internet per logical link > > without per flow state (see Section 5.4). > > However, the price to pay for avoiding flow state for policy is flow > > state to audit ConEx signals, which is discussed further in Section 5.5= =2E=20 > > In summary: i) flow state for auditing does not require route pinning; > > ii) auditing at the edges, with limited per flow state, enables policy > > elsewhere, including in the core, without any per flow state. > > > >" > > > > > >I would make the 2nd part even simpler "A > >suitable auditing design enables policy > >elsewhere, including the core, without any per flow state". > > [BB]: Not sure where you intend 'the 2nd part' to > start. I'd like some residual hint left in the > Intro that we don't need route pinning. How about: > > " One of the design goals of the ConEx protocol is that the important > policy mechanisms can be implemented for heavily aggregated traffic in > the core of the Internet per logical link without > per flow state (see Section 5.4). > However, the price to pay for avoiding flow state for policy is flow > state to audit ConEx signals, which is discussed further in Section 5.5.= =20 > In summary, a suitable edge-based auditing > design using soft per-flow state enables > policy elsewhere, including the core, without any per flow state. > " =46ine with me! > > Also, I forgot to address Mirja's request to move > most of the byte-pkt text from the Intro into the > body. I pushed for that before, so I'll leave you > to argue if you don't agree. While, if you do > agree, you can suggest what to leave, and what to move. Maybe we can have the same approach here. Just leave one sentence saying th= at=20 it is defined in this to count congestion byte-wise and give a reference fo= r=20 a later section for the reasoning. > > > 5) Maybe address briefly how to handle > > ConEx-not-Marked and not ConEx-capable > >packets (not only for partial deployment but also in regular operation). > > They need to be limited somehow as well, otherwise a sender can easily > > cheat by sending ConEx-not-Marked. And this has to be done by the polic= er > > (and not the audit though). > > > > > >I think you mean solely Not-ConEx. > >(ConEx-Not-Marked means Conex-enabled but not > >marked - this highlights that we haven't defined > >that word well; Section 4.5. defines it with the > >same meaning as before, but it hasn't been defined before.). No, I meant also ConEx-Not-Marked because even when you support ConEx you=20 could still send all your packets with ConEx-Not-Marked and the policer and= =20 the audit will not do anything... > > > >There is a para about this in S.6, starting "A > >network operator can create incentives for > >senders to voluntarily reveal ConEx information. ..." > > > >Nonetheless, that in a bullet about senders, so > >I would be happy to write something more > >specific in the section on policy devices, which > >is where this is more relevant. Also, a very > >simple sentence under audit, saying it ignores Not-ConEx. > > > > > > I want to think about this one more: propose something more specific. Okay. > > > >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for > > loss estimation. > > > > > >Today essentially all encryption is above TCP, > >because IPsec does not play nice with NATs, and > >I can't see that changing. Furthermore there > >is already quite a menagerie of FW class devices > >that refuse non-TCP and TCP with nonsensical > >sequence numbers (to thwart various injection > >attacks). We already encrypt nearly all of our > >payload, except some services and some countries. > > > >It feels like this is important from pedantic > >completeness standpoint but not much of an issue in the real world. > > [BB]: Mirja's point was we don't say what can (or > cannot) be done with encrypted TCP. I don't think > she's looking for an evasive answer like "There > probably isn't much encrypted TCP". I don't > believe we should base protocol design on > predictions of the future traffic mix. We should > make the admission clear that we can't do > anything with encrypted TCP (and similarly multipath is tough). Eventhough encrypted TCP is not very common today, if this is the most simp= le=20 way to cheat ConEx, more ConEx deployment could incentivize to send more=20 encrypted packet. Thus there has to be a way to handle this. Maybe we can s= ay=20 something like: "If the TCP header information is encrypted and loss-based= =20 Conex signaling is used, a policer should threat this traffic like not=20 ConEx-capable as auditing is not possible."=20 > > >Let me think about this before you reorganize the section. > > > >Perhaps this would be solved by moving Generic > >loss auditing before the more specific loss > >auditing bullets, because it basically says > >generic isn't possible. Then ending generic loss > >auditing with a linking sentence saying > >"Nonetheless, loss auditing is possible in the following specific > > scenarios." I believe reordering would also help. > > > >In hindsight, we now have another way of doing > >generic loss auditing, which I'd like to add. A > >network can tunnel traffic and turn on ECN in > >the outer, just for the length of the tunnel. > >Then, by RFC6040, the tunnel egress will drop > >any ECN-marked packets with an the inner showing > >that the e2e transport is Not-ECN-capable. > > > >So, an auditor at the tunnel egress will see all > >the congestion signals from within the network > >as ECN, then the tunnel egress will transform > >ECN into drop for those transports that don't support ECN. > > That's a good idea. I would support to put this in the draft. > > > >This isn't really audit is it? What happens if > >a transport says it can do ECN, but just ignores it? It gets more and more ECN markings and will sooner or later get policing=20 drops. That exactly the case were we need ConEx! > > [BB]: Audit checks whether the transport receiver > and/or sender expose the congestion they see > (then policy devices can rely on this exposed > info to police anyone ignoring congestion - if that's the policy). > > The tunnel turns on ECN support in the outer to > ensure any congestion at intermediate nodes can > all be exposed to the auditor as ECN marks not > losses. It works for all packets (even DNS), > whatever the e2e transport says about ECN support (in the inner). > > Nonetheless, for those transports that say they > don't support ECN, the tunnel egress converts all > congestion signals into drops (after the auditor > has read the ECN signals). This 'just works' if > the tunnel complies with RFC6040. > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of > >credits is well enough specified here. My personal option is that credits > >should somehow get invalid (at some point in time). This is left open in > > the current text. > > > > > >I think we need to agree before we can talk > >about writing down what we agree... > > > > > >I think that abstract-mech needs to embrace > >*both*, explicitly if not implicitly. I need to > >think about this some more, but I suspect that > >it means we have unnecessarily over constrained audit here. > > [BB]: We need to allow multiple experiments at > this experimental stage. But ultimately, sources > will need to unambiuously know what Credit means, > so they know how much to introduce and when. > > >Rather than thinking of Credit expiring after a > >time, one can think of the combination of recent > >Re-Echo signals and earlier Credit signals > >keeping the Credit state fresh within a flow. As > >long as you've sent Credit before a round of > >congestion, then if you send Re-Echo afterwards > >the Auditor can switch it round as if you sent > >the Re-Echo before and the Credit after. > > > >So, when the Auditor holds Credit, it allows up > >to that amount of Re-Echo to be considered as > >having been sent before the congestion, rather > >than after. Then, as it switches the Re-Echoes > >back in time, it switches the Credits forward, so they always stay recen= t. > > > >Credit is primarily a mechanism to ensure the > >sender has to suffer some cost before it is > >trusted to pay back some cost. Credit doesn't > >need to degrade over time if the cost to the > >sender of introducing credit doesn't degrade over time. > > > >Does this move us forward, or do you still > >disagree? If so, I suggest a new thread would be useful. > > > > > >This is probably correct, but I really don't think it belongs in A-M. > > [BB]: I don't think it should either. This is a > discussion with Mirja, rather than a proposal for text. I'll send a new main on crediting... > > >Except for the couple of items for more thought, dig in! > > Looking forward to the rest. > > CHeers > > > Bob > > >Thanks, > >--MM-- > >The best way to predict the future is to create it. - Alan Kay > > > >Privacy matters! We know from recent events > >that people are using our services to speak in > >defiance of unjust governments. We treat > >privacy and security as matters of life and > >death, because for some users, they are. > > ________________________________________________________________ > Bob Briscoe, BT =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Sun Jun 9 07:47:13 2013 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 3538221F91BF for ; Sun, 9 Jun 2013 07:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAhCP-TGeEmf for ; Sun, 9 Jun 2013 07:47:09 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3C21F8FA1 for ; Sun, 9 Jun 2013 07:47:08 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0561B60280; Sun, 9 Jun 2013 16:47:08 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id D50476027E; Sun, 9 Jun 2013 16:47:07 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Matt Mathis Date: Sun, 9 Jun 2013 16:47:07 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306041912.r54JCmTJ012702@bagheera.jungle.bt.co.uk> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306091647.07547.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Sun, 09 Jun 2013 14:47:13 -0000 Hi Bob , hi Matt, quickly addressing those points which were not present anymore in the other= =20 mail.... see below... On Thursday 06 June 2013 08:02:06 Matt Mathis wrote: > Follow up to Mirja's and Bob's comments, inline. most are "Looks Good to > Me". > > On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe wrote: > > At 15:12 04/06/2013, Mirja K=FChlewind wrote: > >> 1) The very long title of Figure 1 was kind of confusing me. > > > > OK, we need a caption like "The flow of ConEx signals in the context of > > the pre-existing flows of congestion signals over an end-to-end > > connection" > > > > Then fold the 3-sentence post-amble under the Figure into the body text, > > where it refers to the Figure. > > This is supposed to be a caption (not a title), but yes the RFC formatting > is confusing. I would suggest something even simpler "The flow of > congestion and ConEx signals." and move the rest into the running text. Yes, i would prefer something very short here as well, as the image is well= =20 explained in the text. (Actually the text just above the image basically sa= ys=20 the same that the current caption) [snip] > > 3) Maybe define the term 'congestion signal' in section 2.1 > > > > > > Would the following change to the start of the 2nd para be enough: > > > > OLD > > Networks indicate congestion by three possible signals: packet loss, > > ECN marking or queueing delay. > > NEW > > Networks indicate congestion by three possible congestion signals: > > packet loss, > > ECN marking or queueing delay. > > LGTM I was think about add this definition to 2.1. Terminology like this: Congestion Signal: packet loss or a packet holding the Congestion Experienc= ed=20 (CE) ECN marking I would like to see this to make once again clear, that we only look at los= s=20 and ECN when we talk about congestion in ConEx.=20 > > > 4) I'm not sure that section 4.6 is at the right postion as it seems to > > me > > > >> more related to requirements on the encoding. > > > > We already have the two requirements sentences from Section 4.6 as items > > D & E in Section 3.3. > > > > Would it fix your concern if, instead of just stating these two > > requirements, we make the SHOULDs lower case and refer back to the actu= al > > SHOULD requirements earlier: > > > > OLD > > Therefore a ConEx encoding SHOULD explicity specify whether it > > assumes units of bytes or packets for both congestion indications and > > ConEx markings. > > > > [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion > > indications SHOULD be interpreted in units of bytes when responding to > > congestion, at least on today's Internet. In any TCP implementation > > this is simple to achieve for varying size packets, given TCP SACK > > tracks losses in bytes. If an encoding is specified in units of > > bytes, the encoding SHOULD also specify which headers to include in > > the size of a packet. > > NEW > > This is why a ConEx encoding should explicity specify whether it > > assumes units of bytes or packets for both congestion indications and > > ConEx markings (see requirement D in Section 3.3.). > > > > [I-D.ietf-tsvwg-byte-pkt-**congest] advises that congestion > > indications SHOULD be interpreted in units of bytes when responding to > > congestion, at least on today's Internet. In any TCP implementation > > this is simple to achieve for varying size packets, given TCP SACK > > tracks losses in bytes. If an encoding is specified in units of > > bytes, the encoding should also specify which headers to include in > > the size of a packet (requirement E in Section 3.3). > > LGTM Okay. [snip] > > 9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of > > > credits is well enough specified here. My personal option is that credi= ts > > > >> should somehow get invalid (at some point in time). This is left open = in > >> the > >> current text. > > > > I think we need to agree before we can talk about writing down what we > > agree... > > I think that abstract-mech needs to embrace *both*, explicitly if not > implicitly. I need to think about this some more, but I suspect that it > means we have unnecessarily over constrained audit here. > > > Rather than thinking of Credit expiring after a time, one can think of > > the combination of recent Re-Echo signals and earlier Credit signals > > keeping the Credit state fresh within a flow. As long as you've sent > > Credit before a round of congestion, then if you send Re-Echo after the > > Auditor can switch it round as if you sent the Re-Echo before and the > > Credit after. > > > > So, when the Auditor holds Credit, it allows up to that amount of Re-Ec= ho > > to be considered as having been sent before the congestion, rather than > > after. Then, as it switches the Re-Echoes back in time, it switches the > > Credits forward, so they always stay recent. > > > > Credit is primarily a mechanism to ensure the sender has to suffer some > > cost before it is trusted to pay back some cost. Credit doesn't need to > > degrade over time if the cost to the sender of introducing credit doesn= 't > > degrade over time. > > > > Does this move us forward, or do you still disagree? If so, I suggest a > > new thread would be useful. > > This is probably correct, but I really don't think it belongs in A-M. Where does it belong? > > > 10) In section 6 it is stated that 'Networks MUST NOT change ConEx > > marked > > > >> packets to not_ConEx. [...]'. Maybe move this to the requirement > >> section, otherwise it might be easily overread. > > > > Yes. Thanks. And the same goes for collecting any the other later > > normative language into the requirements section. > > Yep, I agreee Okay. > > > 11) Security Considerations lists a number of attacks. Shouldn't this > > > >> document > >> also give hints how to handle these attacks? Especially for the > >> 'Dragging Down a Spoofed Flow ID', I can't really come up with a good > >> solution...? > > > > You're right that this is the hardest known attack to defend against. T= he > > draft currently refers to my thesis for two solutions. See Section 7.5.3 > > of > > >ojects/refb/#refb-dis> > > > > It also includes an analysis of how difficult this attack is for a blind > > attacker. The attack only works while it sends numerous packets over a > > 5-tuple that matches a target flow. It only has to scan the most fruiful > > parts of the 5-tuple space, but it can't detect when it has hit a match, > > so it has to send large numbers of packets over each 5-tuple just in > > case. BTW, the attack is trivial for a man-in-the-middle, but he can dr= op > > everything anyway. I would prefer a little extra text in this document just like the explanati= on=20 above. > > > > I have promised to transcribe that material into the RFC series > > eventually, but it's not a priority before we get experimental use of > > ConEx. I believe it's OK at this stage as long as the solutions are > > documented /somewhere/ and referred to. > > > > Is that acceptable? > > LGTM > > > Thanks v much for this full review. We needed this. > > Except for the couple of items for more thought, dig in! > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy a= nd > security as matters of life and death, because for some users, they are. =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From mirja.kuehlewind@ikr.uni-stuttgart.de Sun Jun 9 08:03:41 2013 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 21DEC21F8E93 for ; Sun, 9 Jun 2013 08:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykv+4xB7Avxh for ; Sun, 9 Jun 2013 08:03:36 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id C460521F8EAE for ; Sun, 9 Jun 2013 08:03:35 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 9ACB460280; Sun, 9 Jun 2013 17:03:34 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 441076027E; Sun, 9 Jun 2013 17:03:34 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: Bob Briscoe Date: Sun, 9 Jun 2013 17:03:33 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> In-Reply-To: <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> Cc: ConEx IETF list Subject: [conex] Crediting [was: Re: Review of draft-ietf-conex-abstract-mech-06] 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: Sun, 09 Jun 2013 15:03:41 -0000 Hi, so back on this one: > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of > >credits is well enough specified here. My personal option is that credits > >should somehow get invalid (at some point in time). This is left open in > > the current text. > > > > > >I think we need to agree before we can talk > >about writing down what we agree... > > > > > >I think that abstract-mech needs to embrace > >*both*, explicitly if not implicitly. I need to > >think about this some more, but I suspect that > >it means we have unnecessarily over constrained audit here. > > [BB]: We need to allow multiple experiments at > this experimental stage. But ultimately, sources > will need to unambiuously know what Credit means, > so they know how much to introduce and when. Yes, but we need to propose a mechanism when to send credits for the TCP mod draft and this means we need to have a common understanding how to handle credits in the endsystem and the audit. I guess that's what standards are good for. We might need a separate document for this. Not sure we are able to agree on this right now. As an alternative, I could also add some text in the TCP mod draft that the crediting is an open issue for experiments...? > > >Rather than thinking of Credit expiring after a > >time, one can think of the combination of recent > >Re-Echo signals and earlier Credit signals > >keeping the Credit state fresh within a flow. As > >long as you've sent Credit before a round of > >congestion, then if you send Re-Echo afterwards > >the Auditor can switch it round as if you sent > >the Re-Echo before and the Credit after. I don't think this would change anything. Maybe make it even worse. As you could also just send credit instead of ConEx marks and moreover there is still no incentive to send further marks when you have build up a large number of credits during Slow Start. > > > >So, when the Auditor holds Credit, it allows up > >to that amount of Re-Echo to be considered as > >having been sent before the congestion, rather > >than after. Then, as it switches the Re-Echoes > >back in time, it switches the Credits forward, so they always stay recent. > > > >Credit is primarily a mechanism to ensure the > >sender has to suffer some cost before it is > >trusted to pay back some cost. Credit doesn't > >need to degrade over time if the cost to the > >sender of introducing credit doesn't degrade over time. > > > >Does this move us forward, or do you still > >disagree? If so, I suggest a new thread would be useful. I have two concerns: 1) As mentioned above if a sender has sent a large number of credits during Slow Start and causes only few congestion during the rest of the transmission (as today's TCP usually does), there is no incentive to send further ConEx marks at all (neither credits nor loss/ECN ConEx marks). 2) When sufficient markings has been sent during Slow Start, no further credits should be needed. But if the audit for any reason will loose state (e.g. because of memory restriction or a new audit is used due to rerouting), the sender will still not send new credits as will and thus will cause the audit penalize the flow eventhough the sender did do nothing wrong. > > > > > >This is probably correct, but I really don't think it belongs in A-M. We might need an own document but there might also be some additional requirements that should be added to this document. > > [BB]: I don't think it should either. This is a > discussion with Mirja, rather than a proposal for text. From david.wagner@ikr.uni-stuttgart.de Mon Jun 10 10:44:45 2013 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 86CE321F9691 for ; Mon, 10 Jun 2013 10:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfU+zyHxsfav for ; Mon, 10 Jun 2013 10:44:40 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 586E321F8F85 for ; Mon, 10 Jun 2013 10:44:40 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 123366010C; Mon, 10 Jun 2013 19:44:39 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 0BF206010B; Mon, 10 Jun 2013 19:44:39 +0200 (CEST) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: conex@ietf.org Date: Mon, 10 Jun 2013 19:44:38 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> In-Reply-To: <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201306101944.38261.david.wagner@ikr.uni-stuttgart.de> Subject: Re: [conex] Crediting [was: Re: Review of draft-ietf-conex-abstract-mech-06] 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: Mon, 10 Jun 2013 17:44:45 -0000 Hi, I think there are some strong arguments for "aging" credits: 1) they avoid problems with restarted audits / rerouting: if credits are valid for e.g. 1 hour, any newly started auditer should not indicate reliable information for that time. This can be extended to running auditers seeing new (rerouted?) IP addresses, but of course there is a trade-off for coverage. 2) the value for credit is likely to degrade over time for the sender, typically already sent credits will count less than credits to be sent now. This applies for rate-based credit / ConEx allowance mechanisms since, if using non-vanishing credits, the starting phase is much more costly than maintaining a flow. In other words: non-vanishing credit is an incentive to keep connections open. Do we want that? Anyway, I don't yet have a good credit concept. Which also needs to address handling loss of ConEx-marked packets, at the sender and at the audit. David > Hi, > > so back on this one: > > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of > > >credits is well enough specified here. My personal option is that credits > > >should somehow get invalid (at some point in time). This is left open in > > > the current text. > > > > > > > > >I think we need to agree before we can talk > > >about writing down what we agree... > > > > > > > > >I think that abstract-mech needs to embrace > > >*both*, explicitly if not implicitly. I need to > > >think about this some more, but I suspect that > > >it means we have unnecessarily over constrained audit here. > > > > [BB]: We need to allow multiple experiments at > > this experimental stage. But ultimately, sources > > will need to unambiuously know what Credit means, > > so they know how much to introduce and when. > > Yes, but we need to propose a mechanism when to send credits for the TCP mod > draft and this means we need to have a common understanding how to handle > credits in the endsystem and the audit. I guess that's what standards are > good for. We might need a separate document for this. Not sure we are able to > agree on this right now. As an alternative, I could also add some text in the > TCP mod draft that the crediting is an open issue for experiments...? > > > > > >Rather than thinking of Credit expiring after a > > >time, one can think of the combination of recent > > >Re-Echo signals and earlier Credit signals > > >keeping the Credit state fresh within a flow. As > > >long as you've sent Credit before a round of > > >congestion, then if you send Re-Echo afterwards > > >the Auditor can switch it round as if you sent > > >the Re-Echo before and the Credit after. > > I don't think this would change anything. Maybe make it even worse. As you > could also just send credit instead of ConEx marks and moreover there is > still no incentive to send further marks when you have build up a large > number of credits during Slow Start. > > > > > > >So, when the Auditor holds Credit, it allows up > > >to that amount of Re-Echo to be considered as > > >having been sent before the congestion, rather > > >than after. Then, as it switches the Re-Echoes > > >back in time, it switches the Credits forward, so they always stay recent. > > > > > >Credit is primarily a mechanism to ensure the > > >sender has to suffer some cost before it is > > >trusted to pay back some cost. Credit doesn't > > >need to degrade over time if the cost to the > > >sender of introducing credit doesn't degrade over time. > > > > > >Does this move us forward, or do you still > > >disagree? If so, I suggest a new thread would be useful. > > I have two concerns: > 1) As mentioned above if a sender has sent a large number of credits during > Slow Start and causes only few congestion during the rest of the transmission > (as today's TCP usually does), there is no incentive to send further ConEx > marks at all (neither credits nor loss/ECN ConEx marks). > 2) When sufficient markings has been sent during Slow Start, no further > credits should be needed. But if the audit for any reason will loose state > (e.g. because of memory restriction or a new audit is used due to rerouting), > the sender will still not send new credits as will and thus will cause the > audit penalize the flow eventhough the sender did do nothing wrong. > > > > > > > > > >This is probably correct, but I really don't think it belongs in A-M. > > We might need an own document but there might also be some additional > requirements that should be added to this document. > > > > > [BB]: I don't think it should either. This is a > > discussion with Mirja, rather than a proposal for text. > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > -- Dipl.-Inf. David Wagner Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart Pfaffenwaldring 47, D-70569 Stuttgart, Germany web: www.ikr.uni-stuttgart.de email: david.wagner@ikr.uni-stuttgart.de phone: +49 711 685-67965 fax: +49 711 685-57965 ------------------------------------------------------------------- From bob.briscoe@bt.com Thu Jun 13 09:19:45 2013 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 BBF2A21F8904 for ; Thu, 13 Jun 2013 09:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne4DQFe0zwOu for ; Thu, 13 Jun 2013 09:19:31 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5E21F9A59 for ; Thu, 13 Jun 2013 09:19:30 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Jun 2013 17:19:29 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Jun 2013 17:19:28 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Thu, 13 Jun 2013 17:19:23 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.112.140]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r5DGJLkb016461; Thu, 13 Jun 2013 17:19:21 +0100 Message-ID: <201306131619.r5DGJLkb016461@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Jun 2013 17:19:20 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Thu, 13 Jun 2013 16:19:45 -0000 Mirja, Sorry this thread got split up. I haven't=20 responded to any of you points in the other part,=20 because I would just be repeating what I said -=20 I'd like to hear Matt's responses instead. Responses to this part inline... At 15:34 09/06/2013, Mirja Kuehlewind wrote: >Hi Bob, hi Matt, > >see inline.... > >On Friday 07 June 2013 01:57:26 Bob Briscoe wrote: > > Matt, > > > > A few rejoinders inline... > > > > At 07:02 06/06/2013, Matt Mathis wrote: > > >Follow up to Mirja's and Bob's comments, > > >inline. most are "Looks Good to Me". > > > > > > > > >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe > > ><bob.briscoe@bt.com> wrote: > > >At 15:12 04/06/2013, Mirja K=FChlewind wrote: [snip] > > > 5) Maybe address briefly how to handle > > > ConEx-not-Marked and not ConEx-capable > > >packets (not only for partial deployment but also in regular= operation). > > > They need to be limited somehow as well, otherwise a sender can easily > > > cheat by sending ConEx-not-Marked. And this has to be done by the= policer > > > (and not the audit though). > > > > > > > > >I think you mean solely Not-ConEx. > > >(ConEx-Not-Marked means Conex-enabled but not > > >marked - this highlights that we haven't defined > > >that word well; Section 4.5. defines it with the > > >same meaning as before, but it hasn't been defined before.). > >No, I meant also ConEx-Not-Marked because even when you support ConEx you >could still send all your packets with ConEx-Not-Marked and the policer and >the audit will not do anything... [BB]: ConEx-Not-Marked are ConEx enabled, they=20 just say "there is no re-echo". So if, there is=20 congestion but the source only sends=20 ConEx-Not-Marked, it is suppressing re-feedback=20 of the congestion, and the audit function will squash the flow. This is the whole point of the audit function. So=20 perhaps I am misunderstanding your point? > > > > > >There is a para about this in S.6, starting "A > > >network operator can create incentives for > > >senders to voluntarily reveal ConEx information. ..." > > > > > >Nonetheless, that in a bullet about senders, so > > >I would be happy to write something more > > >specific in the section on policy devices, which > > >is where this is more relevant. Also, a very > > >simple sentence under audit, saying it ignores Not-ConEx. > > > > > > > > > I want to think about this one more: propose something more specific. > >[Mirja]: Okay. [BB]: Matt, no time to write text at the mo=20 (about to take a week off, so I'm having to do=20 the week's extra work beforehand). I planned to do this when we add the= edits. > > > > > >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for > > > loss estimation. > > > > > > > > >Today essentially all encryption is above TCP, > > >because IPsec does not play nice with NATs, and > > >I can't see that changing. Furthermore there > > >is already quite a menagerie of FW class devices > > >that refuse non-TCP and TCP with nonsensical > > >sequence numbers (to thwart various injection > > >attacks). We already encrypt nearly all of our > > >payload, except some services and some countries. > > > > > >It feels like this is important from pedantic > > >completeness standpoint but not much of an issue in the real world. > > > > [BB]: Mirja's point was we don't say what can (or > > cannot) be done with encrypted TCP. I don't think > > she's looking for an evasive answer like "There > > probably isn't much encrypted TCP". I don't > > believe we should base protocol design on > > predictions of the future traffic mix. We should > > make the admission clear that we can't do > > anything with encrypted TCP (and similarly multipath is tough). > >Eventhough encrypted TCP is not very common today, if this is the most= simple >way to cheat ConEx, more ConEx deployment could incentivize to send more >encrypted packet. Thus there has to be a way to handle this. Maybe we can= say >something like: "If the TCP header information is encrypted and loss-based >Conex signaling is used, a policer should threat this traffic like not >ConEx-capable as auditing is not possible." [BB]: Superficially, that seems a good sentence.=20 But it wouldn't apply in the cases described=20 where audit can be done against losses. So I would append: ..."unless the operator knows it is using one of=20 the techniques described in Section xxx to audit against losses". > > > > >Let me think about this before you reorganize the section. > > > > > >Perhaps this would be solved by moving Generic > > >loss auditing before the more specific loss > > >auditing bullets, because it basically says > > >generic isn't possible. Then ending generic loss > > >auditing with a linking sentence saying > > >"Nonetheless, loss auditing is possible in the following specific > > > scenarios." > >I believe reordering would also help. [BB]: Matt, have you pondered? Regards Bob > > > > > >In hindsight, we now have another way of doing > > >generic loss auditing, which I'd like to add. A > > >network can tunnel traffic and turn on ECN in > > >the outer, just for the length of the tunnel. > > >Then, by RFC6040, the tunnel egress will drop > > >any ECN-marked packets with an the inner showing > > >that the e2e transport is Not-ECN-capable. > > > > > >So, an auditor at the tunnel egress will see all > > >the congestion signals from within the network > > >as ECN, then the tunnel egress will transform > > >ECN into drop for those transports that don't support ECN. > > > >That's a good idea. I would support to put this in the draft. > > > > > > >This isn't really audit is it? What happens if > > >a transport says it can do ECN, but just ignores it? > >It gets more and more ECN markings and will sooner or later get policing >drops. That exactly the case were we need ConEx! > > > > > [BB]: Audit checks whether the transport receiver > > and/or sender expose the congestion they see > > (then policy devices can rely on this exposed > > info to police anyone ignoring congestion - if that's the policy). > > > > The tunnel turns on ECN support in the outer to > > ensure any congestion at intermediate nodes can > > all be exposed to the auditor as ECN marks not > > losses. It works for all packets (even DNS), > > whatever the e2e transport says about ECN support (in the inner). > > > > Nonetheless, for those transports that say they > > don't support ECN, the tunnel egress converts all > > congestion signals into drops (after the auditor > > has read the ECN signals). This 'just works' if > > the tunnel complies with RFC6040. > > > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning= of > > >credits is well enough specified here. My personal option is that= credits > > >should somehow get invalid (at some point in time). This is left open= in > > > the current text. > > > > > > > > >I think we need to agree before we can talk > > >about writing down what we agree... > > > > > > > > >I think that abstract-mech needs to embrace > > >*both*, explicitly if not implicitly. I need to > > >think about this some more, but I suspect that > > >it means we have unnecessarily over constrained audit here. > > > > [BB]: We need to allow multiple experiments at > > this experimental stage. But ultimately, sources > > will need to unambiuously know what Credit means, > > so they know how much to introduce and when. > > > > >Rather than thinking of Credit expiring after a > > >time, one can think of the combination of recent > > >Re-Echo signals and earlier Credit signals > > >keeping the Credit state fresh within a flow. As > > >long as you've sent Credit before a round of > > >congestion, then if you send Re-Echo afterwards > > >the Auditor can switch it round as if you sent > > >the Re-Echo before and the Credit after. > > > > > >So, when the Auditor holds Credit, it allows up > > >to that amount of Re-Echo to be considered as > > >having been sent before the congestion, rather > > >than after. Then, as it switches the Re-Echoes > > >back in time, it switches the Credits forward, so they always stay= recent. > > > > > >Credit is primarily a mechanism to ensure the > > >sender has to suffer some cost before it is > > >trusted to pay back some cost. Credit doesn't > > >need to degrade over time if the cost to the > > >sender of introducing credit doesn't degrade over time. > > > > > >Does this move us forward, or do you still > > >disagree? If so, I suggest a new thread would be useful. > > > > > > > > >This is probably correct, but I really don't think it belongs in A-M. > > > > [BB]: I don't think it should either. This is a > > discussion with Mirja, rather than a proposal for text. > >I'll send a new main on crediting... > > > > > >Except for the couple of items for more thought, dig in! > > > > Looking forward to the rest. > > > > CHeers > > > > > > Bob > > > > >Thanks, > > >--MM-- > > >The best way to predict the future is to create it. - Alan Kay > > > > > >Privacy matters! We know from recent events > > >that people are using our services to speak in > > >defiance of unjust governments. We treat > > >privacy and security as matters of life and > > >death, because for some users, they are. > > > > ________________________________________________________________ > > Bob Briscoe, BT > > > >-- >------------------------------------------------------------------- >Dipl.-Ing. Mirja K=FChlewind >Institute of Communication Networks and Computer Engineering (IKR) >University of Stuttgart, Germany >Pfaffenwaldring 47, D-70569 Stuttgart > >tel: +49(0)711/685-67973 >email: mirja.kuehlewind@ikr.uni-stuttgart.de >web: www.ikr.uni-stuttgart.de >------------------------------------------------------------------- ________________________________________________________________ Bob Briscoe, BT=20 From mattmathis@google.com Thu Jun 13 17:48:18 2013 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 8B41F21F9B63 for ; Thu, 13 Jun 2013 17:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJe9hq1Fr1mb for ; Thu, 13 Jun 2013 17:48:16 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A289521F9B2D for ; Thu, 13 Jun 2013 17:48:16 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so3272ieb.38 for ; Thu, 13 Jun 2013 17:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ZN10ll3bxkk7JGyjctGkM8TTVZhfXc8noeiXkDPlK8=; b=hCDX8OAbBH891mLsjcv130NmDTqXX/WH7fFR4xAjb2uPWpVZV4K6zZiTGJY6+ItdIQ N4uMGfOxRRWsRKnUiWGLFcbst6vqifN8m1CAhCTelw1SYE0Uxx3QbAQQ9jfvwy6aTp1n oz8/1Idi0Qlsp2pXxPVL0uXAexCvxuBcurck+UmclAWR/HGoSXEf7VIZ5vqrBobp5qMM OzKW4xXr8OaZOpuQvb32/M8agFEHPA6RnIT7FyLWJpIBY5ww9kP0Y9acIbKQA09OTOpd 8BQ3w1egC9g6FA4iqNlXkUIVVSVBMvQALkGnBwdYNxTZfIUmMuFfPGsBM9CzcFQY8Ik4 IrQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8ZN10ll3bxkk7JGyjctGkM8TTVZhfXc8noeiXkDPlK8=; b=H1uF0wLP+DdaW5i3D7pCjBoPusLoAvoDHBEsTlULt+di///qFhQVt1KUgwirOKol0t OSeEGR0xLXALTB+0yi1c6a3EwvUFH0ksci4WtWG0zak2KxbVi8corXQctr10plSqWef/ RI1Z4HE03FhAzGM62TaG5TCZJ5DryxEtSORVBoYxIgmZLzNkYqkcw/p++NBaaE7QPouT oTzEiIpqd5pJv3r2TKLt7TEi/u1CNE0N464CDFa+8FF2Cip+5GqKIs731E7laSdGALxT kjd65khKVQ19W5RvBKeLhFvYJmWmiy12tZ/YSR7RDlVTEs7kpljFxOD0SrSWJyY0wixT GxyA== MIME-Version: 1.0 X-Received: by 10.50.26.67 with SMTP id j3mr9400igg.15.1371170896068; Thu, 13 Jun 2013 17:48:16 -0700 (PDT) Received: by 10.64.25.52 with HTTP; Thu, 13 Jun 2013 17:48:15 -0700 (PDT) In-Reply-To: <201306131619.r5DGJLkb016461@bagheera.jungle.bt.co.uk> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de> <201306131619.r5DGJLkb016461@bagheera.jungle.bt.co.uk> Date: Thu, 13 Jun 2013 17:48:15 -0700 Message-ID: From: Matt Mathis To: Bob Briscoe Content-Type: multipart/alternative; boundary=047d7bd74af62ff2df04df129a96 X-Gm-Message-State: ALoCoQn63XF0wnYUTdHQuqRKITtFzhcJ0CBGx1z7c+flsBEcFBeCoimTN9wVrwa2u0XgMcGZIWgvBuoo8Py5B5izW3hicZRFUZ4W2wI65A4sYxOq0lbPhDGg4vLG6WjLEwCIcl5WrMXFLuHBOh+4jXpxNWQrvXUr5stqIM4DVY3YgQgv3GlHXH9g7Q8LNgGoIVfHar7tYJ0w Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Fri, 14 Jun 2013 00:48:18 -0000 --047d7bd74af62ff2df04df129a96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am buried again - I can't do this justice, nor is it fair for me to hold it up. You may proceeded. Please do the reordering last (or at least late) and capture a copy of the .xml for me just before the reordering so I can easily see the independent changes without the confusion that chaff that the reordering will introduce= . If something makes me too uncomfortable, I will have to argue the changes after the fact. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Thu, Jun 13, 2013 at 9:19 AM, Bob Briscoe wrote: > Mirja, > > Sorry this thread got split up. I haven't responded to any of you points > in the other part, because I would just be repeating what I said - I'd li= ke > to hear Matt's responses instead. > > Responses to this part inline... > > > At 15:34 09/06/2013, Mirja Kuehlewind wrote: > >> Hi Bob, hi Matt, >> >> see inline.... >> >> On Friday 07 June 2013 01:57:26 Bob Briscoe wrote: >> > Matt, >> > >> > A few rejoinders inline... >> > >> > At 07:02 06/06/2013, Matt Mathis wrote: >> > >Follow up to Mirja's and Bob's comments, >> > >inline. most are "Looks Good to Me". >> > > >> > > >> > >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe >> > ><b**ob.briscoe@bt.com = > >> wrote: >> > >At 15:12 04/06/2013, Mirja K=FChlewind wrote: >> > > [snip] > > > > 5) Maybe address briefly how to handle >> > > ConEx-not-Marked and not ConEx-capable >> > >packets (not only for partial deployment but also in regular >> operation). >> > > They need to be limited somehow as well, otherwise a sender can easi= ly >> > > cheat by sending ConEx-not-Marked. And this has to be done by the >> policer >> > > (and not the audit though). >> > > >> > > >> > >I think you mean solely Not-ConEx. >> > >(ConEx-Not-Marked means Conex-enabled but not >> > >marked - this highlights that we haven't defined >> > >that word well; Section 4.5. defines it with the >> > >same meaning as before, but it hasn't been defined before.). >> >> No, I meant also ConEx-Not-Marked because even when you support ConEx yo= u >> could still send all your packets with ConEx-Not-Marked and the policer >> and >> the audit will not do anything... >> > > [BB]: ConEx-Not-Marked are ConEx enabled, they just say "there is no > re-echo". So if, there is congestion but the source only sends > ConEx-Not-Marked, it is suppressing re-feedback of the congestion, and th= e > audit function will squash the flow. > > This is the whole point of the audit function. So perhaps I am > misunderstanding your point? > > > > >> > >There is a para about this in S.6, starting "A >> > >network operator can create incentives for >> > >senders to voluntarily reveal ConEx information. ..." >> > > >> > >Nonetheless, that in a bullet about senders, so >> > >I would be happy to write something more >> > >specific in the section on policy devices, which >> > >is where this is more relevant. Also, a very >> > >simple sentence under audit, saying it ignores Not-ConEx. >> > > >> > > >> > > I want to think about this one more: propose something more specifi= c. >> >> [Mirja]: Okay. >> > > [BB]: Matt, no time to write text at the mo (about to take a week off, so > I'm having to do the week's extra work beforehand). I planned to do this > when we add the edits. > > > > > > >> > >8) Section 5.5 doesn't give any advise how to handle encrypted TCP fo= r >> > > loss estimation. >> > > >> > > >> > >Today essentially all encryption is above TCP, >> > >because IPsec does not play nice with NATs, and >> > >I can't see that changing. Furthermore there >> > >is already quite a menagerie of FW class devices >> > >that refuse non-TCP and TCP with nonsensical >> > >sequence numbers (to thwart various injection >> > >attacks). We already encrypt nearly all of our >> > >payload, except some services and some countries. >> > > >> > >It feels like this is important from pedantic >> > >completeness standpoint but not much of an issue in the real world. >> > >> > [BB]: Mirja's point was we don't say what can (or >> > cannot) be done with encrypted TCP. I don't think >> > she's looking for an evasive answer like "There >> > probably isn't much encrypted TCP". I don't >> > believe we should base protocol design on >> > predictions of the future traffic mix. We should >> > make the admission clear that we can't do >> > anything with encrypted TCP (and similarly multipath is tough). >> >> Eventhough encrypted TCP is not very common today, if this is the most >> simple >> way to cheat ConEx, more ConEx deployment could incentivize to send more >> encrypted packet. Thus there has to be a way to handle this. Maybe we ca= n >> say >> something like: "If the TCP header information is encrypted and loss-bas= ed >> Conex signaling is used, a policer should threat this traffic like not >> ConEx-capable as auditing is not possible." >> > > [BB]: Superficially, that seems a good sentence. But it wouldn't apply in > the cases described where audit can be done against losses. So I would > append: > > ..."unless the operator knows it is using one of the techniques described > in Section xxx to audit against losses". > > > > > >> > >Let me think about this before you reorganize the section. >> > > >> > >Perhaps this would be solved by moving Generic >> > >loss auditing before the more specific loss >> > >auditing bullets, because it basically says >> > >generic isn't possible. Then ending generic loss >> > >auditing with a linking sentence saying >> > >"Nonetheless, loss auditing is possible in the following specific >> > > scenarios." >> >> I believe reordering would also help. >> > > [BB]: Matt, have you pondered? > > Regards > > > > Bob > > > > > >> > >In hindsight, we now have another way of doing >> > >generic loss auditing, which I'd like to add. A >> > >network can tunnel traffic and turn on ECN in >> > >the outer, just for the length of the tunnel. >> > >Then, by RFC6040, the tunnel egress will drop >> > >any ECN-marked packets with an the inner showing >> > >that the e2e transport is Not-ECN-capable. >> > > >> > >So, an auditor at the tunnel egress will see all >> > >the congestion signals from within the network >> > >as ECN, then the tunnel egress will transform >> > >ECN into drop for those transports that don't support ECN. >> > > >> That's a good idea. I would support to put this in the draft. >> >> > > >> > >This isn't really audit is it? What happens if >> > >a transport says it can do ECN, but just ignores it? >> >> It gets more and more ECN markings and will sooner or later get policing >> drops. That exactly the case were we need ConEx! >> >> > >> > [BB]: Audit checks whether the transport receiver >> > and/or sender expose the congestion they see >> > (then policy devices can rely on this exposed >> > info to police anyone ignoring congestion - if that's the policy). >> > >> > The tunnel turns on ECN support in the outer to >> > ensure any congestion at intermediate nodes can >> > all be exposed to the auditor as ECN marks not >> > losses. It works for all packets (even DNS), >> > whatever the e2e transport says about ECN support (in the inner). >> > >> > Nonetheless, for those transports that say they >> > don't support ECN, the tunnel egress converts all >> > congestion signals into drops (after the auditor >> > has read the ECN signals). This 'just works' if >> > the tunnel complies with RFC6040. >> > >> > >9) Section 5.5.1 introdues the credit concept. Not sure if the meanin= g >> of >> > >credits is well enough specified here. My personal option is that >> credits >> > >should somehow get invalid (at some point in time). This is left open >> in >> > > the current text. >> > > >> > > >> > >I think we need to agree before we can talk >> > >about writing down what we agree... >> > > >> > > >> > >I think that abstract-mech needs to embrace >> > >*both*, explicitly if not implicitly. I need to >> > >think about this some more, but I suspect that >> > >it means we have unnecessarily over constrained audit here. >> > >> > [BB]: We need to allow multiple experiments at >> > this experimental stage. But ultimately, sources >> > will need to unambiuously know what Credit means, >> > so they know how much to introduce and when. >> > >> > >Rather than thinking of Credit expiring after a >> > >time, one can think of the combination of recent >> > >Re-Echo signals and earlier Credit signals >> > >keeping the Credit state fresh within a flow. As >> > >long as you've sent Credit before a round of >> > >congestion, then if you send Re-Echo afterwards >> > >the Auditor can switch it round as if you sent >> > >the Re-Echo before and the Credit after. >> > > >> > >So, when the Auditor holds Credit, it allows up >> > >to that amount of Re-Echo to be considered as >> > >having been sent before the congestion, rather >> > >than after. Then, as it switches the Re-Echoes >> > >back in time, it switches the Credits forward, so they always stay >> recent. >> > > >> > >Credit is primarily a mechanism to ensure the >> > >sender has to suffer some cost before it is >> > >trusted to pay back some cost. Credit doesn't >> > >need to degrade over time if the cost to the >> > >sender of introducing credit doesn't degrade over time. >> > > >> > >Does this move us forward, or do you still >> > >disagree? If so, I suggest a new thread would be useful. >> > > >> > > >> > >This is probably correct, but I really don't think it belongs in A-M. >> > >> > [BB]: I don't think it should either. This is a >> > discussion with Mirja, rather than a proposal for text. >> >> I'll send a new main on crediting... >> >> > >> > >Except for the couple of items for more thought, dig in! >> > >> > Looking forward to the rest. >> > >> > CHeers >> > >> > >> > Bob >> > >> > >Thanks, >> > >--MM-- >> > >The best way to predict the future is to create it. - Alan Kay >> > > >> > >Privacy matters! We know from recent events >> > >that people are using our services to speak in >> > >defiance of unjust governments. We treat >> > >privacy and security as matters of life and >> > >death, because for some users, they are. >> > >> > ______________________________**______________________________**____ >> > Bob Briscoe, BT >> >> >> >> -- >> ------------------------------**------------------------------**------- >> Dipl.-Ing. Mirja K=FChlewind >> Institute of Communication Networks and Computer Engineering (IKR) >> University of Stuttgart, Germany >> Pfaffenwaldring 47, D-70569 Stuttgart >> >> tel: +49(0)711/685-67973 >> email: mirja.kuehlewind@ikr.uni-**stuttgart.de >> web: www.ikr.uni-stuttgart.de >> ------------------------------**------------------------------**------- >> > > ______________________________**______________________________**____ > Bob Briscoe, BT > --047d7bd74af62ff2df04df129a96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I am buried again - I can't do this justice, nor is it= fair for me to hold it up. =A0You may proceeded.

Please= do the reordering last (or at least late) and capture a copy of the .xml f= or me just before the reordering so I can easily see the independent change= s without the confusion that chaff that the reordering will introduce.

If something makes me too uncomfortable, I will have t= o argue the changes after the fact.
<= br clear=3D"all">
Thanks,
--MM--
The best= way to predict the future is to create it. =A0- Alan Kay

Privacy matters! =A0We know from recent events that people are using ou= r services to speak in defiance of unjust governments. =A0 We treat privacy= and security as matters of life and death, because for some users, they ar= e.


On Thu, Jun 13, 2013 at 9:19 AM, Bob Bri= scoe <bob.briscoe@bt.com> wrote:
Mirja,

Sorry this thread got split up. I haven't responded to any of you point= s in the other part, because I would just be repeating what I said - I'= d like to hear Matt's responses instead.

Responses to this part inline...


At 15:34 09/06/2013, Mirja Kuehlewind wrote:
Hi Bob, hi Matt,

see inline....

On Friday 07 June 2013 01:57:26 Bob Briscoe wrote:
> Matt,
>
> A few rejoinders inline...
>
> At 07:02 06/06/2013, Matt Mathis wrote:
> >Follow up to Mirja's and Bob's comments,
> >inline. =A0 most are "Looks Good to Me".
> >
> >
> >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe
> ><<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> wrote:
> >At 15:12 04/06/2013, Mirja K=FChlewind wrote:

[snip]

> > =A05) Maybe address briefly how to handle
> > ConEx-not-Marked and not ConEx-capable
> >packets (not only for partial deployment but also in regular opera= tion).
> > They need to be limited somehow as well, otherwise a sender can e= asily
> > cheat by sending ConEx-not-Marked. And this has to be done by the= policer
> > (and not the audit though).
> >
> >
> >I think you mean solely Not-ConEx.
> >(ConEx-Not-Marked means Conex-enabled but not
> >marked - this highlights that we haven't defined
> >that word well; Section 4.5. defines it with the
> >same meaning as before, but it hasn't been defined before.).
No, I meant also ConEx-Not-Marked because even when you support ConEx you could still send all your packets with ConEx-Not-Marked and the policer and=
the audit will not do anything...

[BB]: ConEx-Not-Marked are ConEx enabled, they just say "there is no r= e-echo". So if, there is congestion but the source only sends ConEx-No= t-Marked, it is suppressing re-feedback of the congestion, and the audit fu= nction will squash the flow.

This is the whole point of the audit function. So perhaps I am misunderstan= ding your point?

> >
> >There is a para about this in S.6, starting "A
> >network operator can create incentives for
> >senders to voluntarily reveal ConEx information. ..."
> >
> >Nonetheless, that in a bullet about senders, so
> >I would be happy to write something more
> >specific in the section on policy devices, which
> >is where this is more relevant. Also, a very
> >simple sentence under audit, saying it ignores Not-ConEx.
> >
> >
> > =A0I want to think about this one more: propose something more sp= ecific.

[Mirja]: Okay.

[BB]: Matt, no time to write text at the mo (about to take a week off, so I= 'm having to do the week's extra work beforehand). I planned to do = this when we add the edits.



> >
> >8) Section 5.5 doesn't give any advise how to handle encrypted= TCP for
> > loss estimation.
> >
> >
> >Today essentially all encryption is above TCP,
> >because IPsec does not play nice with NATs, and
> >I can't see that changing. =A0 =A0Furthermore there
> >is already quite a menagerie of FW class devices
> >that refuse non-TCP and TCP with nonsensical
> >sequence numbers (to thwart various injection
> >attacks). =A0We already encrypt nearly all of our
> >payload, except some services and some countries.
> >
> >It feels like this is important from pedantic
> >completeness standpoint but not much of an issue in the real world= .
>
> [BB]: Mirja's point was we don't say what can (or
> cannot) be done with encrypted TCP. I don't think
> she's looking for an evasive answer like "There
> probably isn't much encrypted TCP". I don't
> believe we should base protocol design on
> predictions of the future traffic mix. We should
> make the admission clear that we can't do
> anything with encrypted TCP (and similarly multipath is tough).

Eventhough encrypted TCP is not very common today, if this is the most simp= le
way to cheat ConEx, more ConEx deployment could incentivize to send more encrypted packet. Thus there has to be a way to handle this. Maybe we can s= ay
something like: "If the TCP header information is encrypted and loss-b= ased
Conex signaling is used, a policer should threat this traffic like not
ConEx-capable as auditing is not possible."

[BB]: Superficially, that seems a good sentence. But it wouldn't apply = in the cases described where audit can be done against losses. So I would a= ppend:

..."unless the operator knows it is using one of the techniques descri= bed in Section xxx to audit against losses".



>
> >Let me think about this before you reorganize the section.
> >
> >Perhaps this would be solved by moving Generic
> >loss auditing before the more specific loss
> >auditing bullets, because it basically says
> >generic isn't possible. Then ending generic loss
> >auditing with a linking sentence saying
> >"Nonetheless, loss auditing is possible in the following spec= ific
> > scenarios."

I believe reordering would also help.

[BB]: Matt, have you pondered?

Regards



Bob


> >
> >In hindsight, we now have another way of doing
> >generic loss auditing, which I'd like to add. A
> >network can tunnel traffic and turn on ECN in
> >the outer, just for the length of the tunnel.
> >Then, by RFC6040, the tunnel egress will drop
> >any ECN-marked packets with an the inner showing
> >that the e2e transport is Not-ECN-capable.
> >
> >So, an auditor at the tunnel egress will see all
> >the congestion signals from within the network
> >as ECN, then the tunnel egress will transform
> >ECN into drop for those transports that don't support ECN.
> >
That's a good idea. I would support to put this in the draft.

> >
> >This isn't really audit is it? =A0What happens if
> >a transport says it can do ECN, but just ignores it?

It gets more and more ECN markings and will sooner or later get policing drops. That exactly the case were we need ConEx!

>
> [BB]: Audit checks whether the transport receiver
> and/or sender expose the congestion they see
> (then policy devices can rely on this exposed
> info to police anyone ignoring congestion - if that's the policy).=
>
> The tunnel turns on ECN support in the outer to
> ensure any congestion at intermediate nodes can
> all be exposed to the auditor as ECN marks not
> losses. It works for all packets (even DNS),
> whatever the e2e transport says about ECN support (in the inner).
>
> Nonetheless, for those transports that say they
> don't support ECN, the tunnel egress converts all
> congestion signals into drops (after the auditor
> has read the ECN signals). This 'just works' if
> the tunnel complies with RFC6040.
>
> >9) Section 5.5.1 introdues the credit concept. Not sure if the mea= ning of
> >credits is well enough specified here. My personal option is that = credits
> >should somehow get invalid (at some point in time). This is left o= pen in
> > the current text.
> >
> >
> >I think we need to agree before we can talk
> >about writing down what we agree...
> >
> >
> >I think that abstract-mech needs to embrace
> >*both*, explicitly if not implicitly. =A0I need to
> >think about this some more, but I suspect that
> >it means we have unnecessarily over constrained audit here.
>
> [BB]: We need to allow multiple experiments at
> this experimental stage. But ultimately, sources
> will need to unambiuously know what Credit means,
> so they know how much to introduce and when.
>
> >Rather than thinking of Credit expiring after a
> >time, one can think of the combination of recent
> >Re-Echo signals and earlier Credit signals
> >keeping the Credit state fresh within a flow. As
> >long as you've sent Credit before a round of
> >congestion, then if you send Re-Echo afterwards
> >the Auditor can switch it round as if you sent
> >the Re-Echo before and the Credit after.
> >
> >So, when the Auditor holds Credit, it allows up
> >to that amount of Re-Echo to be considered as
> >having been sent before the congestion, rather
> >than after. Then, as it switches the Re-Echoes
> >back in time, it switches the Credits forward, so they always stay= recent.
> >
> >Credit is primarily a mechanism to ensure the
> >sender has to suffer some cost before it is
> >trusted to pay back some cost. Credit doesn't
> >need to degrade over time if the cost to the
> >sender of introducing credit doesn't degrade over time.
> >
> >Does this move us forward, or do you still
> >disagree? If so, I suggest a new thread would be useful.
> >
> >
> >This is probably correct, but I really don't think it belongs = in A-M.
>
> [BB]: I don't think it should either. This is a
> discussion with Mirja, rather than a proposal for text.

I'll send a new main on crediting...

>
> >Except for the couple of items for more thought, dig in!
>
> Looking forward to the rest.
>
> CHeers
>
>
> Bob
>
> >Thanks,
> >--MM--
> >The best way to predict the future is to create it. =A0- Alan Kay<= br> > >
> >Privacy matters! =A0We know from recent events
> >that people are using our services to speak in
> >defiance of unjust governments. =A0 We treat
> >privacy and security as matters of life and
> >death, because for some users, they are.
>
> ____________________________________________________________= ____
> Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BT



--
-------------------------------------------------------------= ------
Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.= uni-stuttgart.de
-------------------------------------------------------------= ------

_____________________________________________________________= ___
Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BT

--047d7bd74af62ff2df04df129a96-- From bob.briscoe@bt.com Fri Jun 14 14:37:05 2013 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 C87F221F9AE2 for ; Fri, 14 Jun 2013 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1iB-yXeq5jH for ; Fri, 14 Jun 2013 14:37:00 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id E43F721F9AE8 for ; Fri, 14 Jun 2013 14:36:59 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 14 Jun 2013 22:36:58 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 14 Jun 2013 22:36:57 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 14 Jun 2013 22:36:57 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.15.181]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r5ELasbX020674; Fri, 14 Jun 2013 22:36:55 +0100 Message-ID: <201306142136.r5ELasbX020674@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Jun 2013 22:36:53 +0100 To: Matt Mathis From: Bob Briscoe In-Reply-To: References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de> <201306131619.r5DGJLkb016461@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_286535476==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06 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: Fri, 14 Jun 2013 21:37:05 -0000 --=====================_286535476==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Matt, I won't be doing the edits for a week at least. We can wait for your= thoughts. Bob At 01:48 14/06/2013, Matt Mathis wrote: >I am buried again - I can't do this justice, nor=20 >is it fair for me to hold it up. You may proceeded. > >Please do the reordering last (or at least late)=20 >and capture a copy of the .xml for me just=20 >before the reordering so I can easily see the=20 >independent changes without the confusion that=20 >chaff that the reordering will introduce. > >If something makes me too uncomfortable, I will=20 >have to argue the changes after the fact. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > >Privacy matters! We know from recent events=20 >that people are using our services to speak in=20 >defiance of unjust governments. We treat=20 >privacy and security as matters of life and=20 >death, because for some users, they are. > > >On Thu, Jun 13, 2013 at 9:19 AM, Bob Briscoe=20 ><bob.briscoe@bt.com> wrote: >Mirja, > >Sorry this thread got split up. I haven't=20 >responded to any of you points in the other=20 >part, because I would just be repeating what I=20 >said - I'd like to hear Matt's responses instead. > >Responses to this part inline... > > >At 15:34 09/06/2013, Mirja Kuehlewind wrote: >Hi Bob, hi Matt, > >see inline.... > >On Friday 07 June 2013 01:57:26 Bob Briscoe wrote: > > Matt, > > > > A few rejoinders inline... > > > > At 07:02 06/06/2013, Matt Mathis wrote: > > >Follow up to Mirja's and Bob's comments, > > >inline. most are "Looks Good to Me". > > > > > > > > >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe > > >< oe@bt.com>bob.briscoe@bt.com> wrote: > > >At 15:12 04/06/2013, Mirja K=FChlewind wrote: > > >[snip] > > > > 5) Maybe address briefly how to handle > > > ConEx-not-Marked and not ConEx-capable > > >packets (not only for partial deployment but also in regular= operation). > > > They need to be limited somehow as well, otherwise a sender can easily > > > cheat by sending ConEx-not-Marked. And this has to be done by the= policer > > > (and not the audit though). > > > > > > > > >I think you mean solely Not-ConEx. > > >(ConEx-Not-Marked means Conex-enabled but not > > >marked - this highlights that we haven't defined > > >that word well; Section 4.5. defines it with the > > >same meaning as before, but it hasn't been defined before.). > >No, I meant also ConEx-Not-Marked because even when you support ConEx you >could still send all your packets with ConEx-Not-Marked and the policer and >the audit will not do anything... > > >[BB]: ConEx-Not-Marked are ConEx enabled, they=20 >just say "there is no re-echo". So if, there is=20 >congestion but the source only sends=20 >ConEx-Not-Marked, it is suppressing re-feedback=20 >of the congestion, and the audit function will squash the flow. > >This is the whole point of the audit function.=20 >So perhaps I am misunderstanding your point? > > > > > > >There is a para about this in S.6, starting "A > > >network operator can create incentives for > > >senders to voluntarily reveal ConEx information. ..." > > > > > >Nonetheless, that in a bullet about senders, so > > >I would be happy to write something more > > >specific in the section on policy devices, which > > >is where this is more relevant. Also, a very > > >simple sentence under audit, saying it ignores Not-ConEx. > > > > > > > > > I want to think about this one more: propose something more specific. > >[Mirja]: Okay. > > >[BB]: Matt, no time to write text at the mo=20 >(about to take a week off, so I'm having to do=20 >the week's extra work beforehand). I planned to do this when we add the= edits. > > > > > > > > >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for > > > loss estimation. > > > > > > > > >Today essentially all encryption is above TCP, > > >because IPsec does not play nice with NATs, and > > >I can't see that changing. Furthermore there > > >is already quite a menagerie of FW class devices > > >that refuse non-TCP and TCP with nonsensical > > >sequence numbers (to thwart various injection > > >attacks). We already encrypt nearly all of our > > >payload, except some services and some countries. > > > > > >It feels like this is important from pedantic > > >completeness standpoint but not much of an issue in the real world. > > > > [BB]: Mirja's point was we don't say what can (or > > cannot) be done with encrypted TCP. I don't think > > she's looking for an evasive answer like "There > > probably isn't much encrypted TCP". I don't > > believe we should base protocol design on > > predictions of the future traffic mix. We should > > make the admission clear that we can't do > > anything with encrypted TCP (and similarly multipath is tough). > >Eventhough encrypted TCP is not very common today, if this is the most= simple >way to cheat ConEx, more ConEx deployment could incentivize to send more >encrypted packet. Thus there has to be a way to handle this. Maybe we can= say >something like: "If the TCP header information is encrypted and loss-based >Conex signaling is used, a policer should threat this traffic like not >ConEx-capable as auditing is not possible." > > >[BB]: Superficially, that seems a good sentence.=20 >But it wouldn't apply in the cases described=20 >where audit can be done against losses. So I would append: > >..."unless the operator knows it is using one of=20 >the techniques described in Section xxx to audit against losses". > > > > > > > >Let me think about this before you reorganize the section. > > > > > >Perhaps this would be solved by moving Generic > > >loss auditing before the more specific loss > > >auditing bullets, because it basically says > > >generic isn't possible. Then ending generic loss > > >auditing with a linking sentence saying > > >"Nonetheless, loss auditing is possible in the following specific > > > scenarios." > >I believe reordering would also help. > > >[BB]: Matt, have you pondered? > >Regards > > > >Bob > > > > > > > >In hindsight, we now have another way of doing > > >generic loss auditing, which I'd like to add. A > > >network can tunnel traffic and turn on ECN in > > >the outer, just for the length of the tunnel. > > >Then, by RFC6040, the tunnel egress will drop > > >any ECN-marked packets with an the inner showing > > >that the e2e transport is Not-ECN-capable. > > > > > >So, an auditor at the tunnel egress will see all > > >the congestion signals from within the network > > >as ECN, then the tunnel egress will transform > > >ECN into drop for those transports that don't support ECN. > > > >That's a good idea. I would support to put this in the draft. > > > > > > >This isn't really audit is it? What happens if > > >a transport says it can do ECN, but just ignores it? > >It gets more and more ECN markings and will sooner or later get policing >drops. That exactly the case were we need ConEx! > > > > > [BB]: Audit checks whether the transport receiver > > and/or sender expose the congestion they see > > (then policy devices can rely on this exposed > > info to police anyone ignoring congestion - if that's the policy). > > > > The tunnel turns on ECN support in the outer to > > ensure any congestion at intermediate nodes can > > all be exposed to the auditor as ECN marks not > > losses. It works for all packets (even DNS), > > whatever the e2e transport says about ECN support (in the inner). > > > > Nonetheless, for those transports that say they > > don't support ECN, the tunnel egress converts all > > congestion signals into drops (after the auditor > > has read the ECN signals). This 'just works' if > > the tunnel complies with RFC6040. > > > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning= of > > >credits is well enough specified here. My personal option is that= credits > > >should somehow get invalid (at some point in time). This is left open= in > > > the current text. > > > > > > > > >I think we need to agree before we can talk > > >about writing down what we agree... > > > > > > > > >I think that abstract-mech needs to embrace > > >*both*, explicitly if not implicitly. I need to > > >think about this some more, but I suspect that > > >it means we have unnecessarily over constrained audit here. > > > > [BB]: We need to allow multiple experiments at > > this experimental stage. But ultimately, sources > > will need to unambiuously know what Credit means, > > so they know how much to introduce and when. > > > > >Rather than thinking of Credit expiring after a > > >time, one can think of the combination of recent > > >Re-Echo signals and earlier Credit signals > > >keeping the Credit state fresh within a flow. As > > >long as you've sent Credit before a round of > > >congestion, then if you send Re-Echo afterwards > > >the Auditor can switch it round as if you sent > > >the Re-Echo before and the Credit after. > > > > > >So, when the Auditor holds Credit, it allows up > > >to that amount of Re-Echo to be considered as > > >having been sent before the congestion, rather > > >than after. Then, as it switches the Re-Echoes > > >back in time, it switches the Credits forward, so they always stay= recent. > > > > > >Credit is primarily a mechanism to ensure the > > >sender has to suffer some cost before it is > > >trusted to pay back some cost. Credit doesn't > > >need to degrade over time if the cost to the > > >sender of introducing credit doesn't degrade over time. > > > > > >Does this move us forward, or do you still > > >disagree? If so, I suggest a new thread would be useful. > > > > > > > > >This is probably correct, but I really don't think it belongs in A-M. > > > > [BB]: I don't think it should either. This is a > > discussion with Mirja, rather than a proposal for text. > >I'll send a new main on crediting... > > > > > >Except for the couple of items for more thought, dig in! > > > > Looking forward to the rest. > > > > CHeers > > > > > > Bob > > > > >Thanks, > > >--MM-- > > >The best way to predict the future is to create it. - Alan Kay > > > > > >Privacy matters! We know from recent events > > >that people are using our services to speak in > > >defiance of unjust governments. We treat > > >privacy and security as matters of life and > > >death, because for some users, they are. > > > > ________________________________________________________________ > > Bob Briscoe, BT > > > >-- >------------------------------------------------------------------- >Dipl.-Ing. Mirja K=FChlewind >Institute of Communication Networks and Computer Engineering (IKR) >University of Stuttgart, Germany >Pfaffenwaldring 47, D-70569 Stuttgart > >tel: +49(0)711/685-67973 >email:=20 >mirja.kuehlewind@ikr.uni-stut= tgart.de >web: www.ikr.uni-stuttgart.de >------------------------------------------------------------------- > > >________________________________________________________________ >Bob Briscoe, BT > ________________________________________________________________ Bob Briscoe, BT=20 --=====================_286535476==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Matt,

I won't be doing the edits for a week at least. We can wait for your thoughts.


Bob

At 01:48 14/06/2013, Matt Mathis wrote:
I am buried again - I can't d= o this justice, nor is it fair for me to hold it up.  You may proceeded.

Please do the reordering last (or at least late) and capture a copy of the .xml for me just before the reordering so I can easily see the independent changes without the confusion that chaff that the reordering will introduce.

If something makes me too uncomfortable, I will have to argue the changes after the fact.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.


On Thu, Jun 13, 2013 at 9:19 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:
Mirja,

Sorry this thread got split up. I haven't responded to any of you points in the other part, because I would just be repeating what I said - I'd like to hear Matt's responses instead.

Responses to this part inline...


At 15:34 09/06/2013, Mirja Kuehlewind wrote:
Hi Bob, hi Matt,

see inline....

On Friday 07 June 2013 01:57:26 Bob Briscoe wrote:
> Matt,
>
> A few rejoinders inline...
>
> At 07:02 06/06/2013, Matt Mathis wrote:
> >Follow up to Mirja's and Bob's comments,
> >inline.   most are "Looks Good to Me".
> >
> >
> >On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe
> ><< mailto:bob.briscoe@bt.com> bob.briscoe@bt.com> wrote:
> >At 15:12 04/06/2013, Mirja K=FChlewind wrote:


[snip]

> >  5) Maybe address briefly how to handle
> > ConEx-not-Marked and not ConEx-capable
> >packets (not only for partial deployment but also in regular operation).
> > They need to be limited somehow as well, otherwise a sender can easily
> > cheat by sending ConEx-not-Marked. And this has to be done by the policer
> > (and not the audit though).
> >
> >
> >I think you mean solely Not-ConEx.
> >(ConEx-Not-Marked means Conex-enabled but not
> >marked - this highlights that we haven't defined
> >that word well; Section 4.5. defines it with the
> >same meaning as before, but it hasn't been defined before.).

No, I meant also ConEx-Not-Marked because even when you support ConEx you
could still send all your packets with ConEx-Not-Marked and the policer and
the audit will not do anything...


[BB]: ConEx-Not-Marked are ConEx enabled, they just say "there is no re-echo". So if, there is congestion but the source only sends ConEx-Not-Marked, it is suppressing re-feedback of the congestion, and the audit function will squash the flow.

This is the whole point of the audit function. So perhaps I am misunderstanding your point?

> >
> >There is a para about this in S.6, starting "A
> >network operator can create incentives for
> >senders to voluntarily reveal ConEx information. ..."
> >
> >Nonetheless, that in a bullet about senders, so
> >I would be happy to write something more
> >specific in the section on policy devices, which
> >is where this is more relevant. Also, a very
> >simple sentence under audit, saying it ignores Not-ConEx.
> >
> >
> >  I want to think about this one more: propose something more specific.

[Mirja]: Okay.


[BB]: Matt, no time to write text at the mo (about to take a week off, so I'm having to do the week's extra work beforehand). I planned to do this when we add the edits.



> >
> >8) Section 5.5 doesn't give any advise how to handle encrypted TCP for
> > loss estimation.
> >
> >
> >Today essentially all encryption is above TCP,
> >because IPsec does not play nice with NATs, and
> >I can't see that changing.    Furthermore there
> >is already quite a menagerie of FW class devices
> >that refuse non-TCP and TCP with nonsensical
> >sequence numbers (to thwart various injection
> >attacks).  We already encrypt nearly all of our
> >payload, except some services and some countries.
> >
> >It feels like this is important from pedantic
> >completeness standpoint but not much of an issue in the real world.
>
> [BB]: Mirja's point was we don't say what can (or
> cannot) be done with encrypted TCP. I don't think
> she's looking for an evasive answer like "There
> probably isn't much encrypted TCP". I don't
> believe we should base protocol design on
> predictions of the future traffic mix. We should
> make the admission clear that we can't do
> anything with encrypted TCP (and similarly multipath is tough).

Eventhough encrypted TCP is not very common today, if this is the most simple
way to cheat ConEx, more ConEx deployment could incentivize to send more
encrypted packet. Thus there has to be a way to handle this. Maybe we can say
something like: "If the TCP header information is encrypted and loss-based
Conex signaling is used, a policer should threat this traffic like not
ConEx-capable as auditing is not possible."


[BB]: Superficially, that seems a good sentence. But it wouldn't apply in the cases described where audit can be done against losses. So I would append:

..."unless the operator knows it is using one of the techniques described in Section xxx to audit against losses".



>
> >Let me think about this before you reorganize the section.
> >
> >Perhaps this would be solved by moving Generic
> >loss auditing before the more specific loss
> >auditing bullets, because it basically says
> >generic isn't possible. Then ending generic loss
> >auditing with a linking sentence saying
> >"Nonetheless, loss auditing is possible in the following specific
> > scenarios."

I believe reordering would also help.


[BB]: Matt, have you pondered?

Regards



Bob


> >
> >In hindsight, we now have another way of doing
> >generic loss auditing, which I'd like to add. A
> >network can tunnel traffic and turn on ECN in
> >the outer, just for the length of the tunnel.
> >Then, by RFC6040, the tunnel egress will drop
> >any ECN-marked packets with an the inner showing
> >that the e2e transport is Not-ECN-capable.
> >
> >So, an auditor at the tunnel egress will see all
> >the congestion signals from within the network
> >as ECN, then the tunnel egress will transform
> >ECN into drop for those transports that don't support ECN.
> >
That's a good idea. I would support to put this in the draft.

> >
> >This isn't really audit is it?  What happens if
> >a transport says it can do ECN, but just ignores it?

It gets more and more ECN markings and will sooner or later get policing
drops. That exactly the case were we need ConEx!

>
> [BB]: Audit checks whether the transport receiver
> and/or sender expose the congestion they see
> (then policy devices can rely on this exposed
> info to police anyone ignoring congestion - if that's the policy).
>
> The tunnel turns on ECN support in the outer to
> ensure any congestion at intermediate nodes can
> all be exposed to the auditor as ECN marks not
> losses. It works for all packets (even DNS),
> whatever the e2e transport says about ECN support (in the inner).
>
> Nonetheless, for those transports that say they
> don't support ECN, the tunnel egress converts all
> congestion signals into drops (after the auditor
> has read the ECN signals). This 'just works' if
> the tunnel complies with RFC6040.
>
> >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of
> >credits is well enough specified here. My personal option is that credits
> >should somehow get invalid (at some point in time). This is left open in
> > the current text.
> >
> >
> >I think we need to agree before we can talk
> >about writing down what we agree...
> >
> >
> >I think that abstract-mech needs to embrace
> >*both*, explicitly if not implicitly.  I need to
> >think about this some more, but I suspect that
> >it means we have unnecessarily over constrained audit here.
>
> [BB]: We need to allow multiple experiments at
> this experimental stage. But ultimately, sources
> will need to unambiuously know what Credit means,
> so they know how much to introduce and when.
>
> >Rather than thinking of Credit expiring after a
> >time, one can think of the combination of recent
> >Re-Echo signals and earlier Credit signals
> >keeping the Credit state fresh within a flow. As
> >long as you've sent Credit before a round of
> >congestion, then if you send Re-Echo afterwards
> >the Auditor can switch it round as if you sent
> >the Re-Echo before and the Credit after.
> >
> >So, when the Auditor holds Credit, it allows up
> >to that amount of Re-Echo to be considered as
> >having been sent before the congestion, rather
> >than after. Then, as it switches the Re-Echoes
> >back in time, it switches the Credits forward, so they always stay recent.
> >
> >Credit is primarily a mechanism to ensure the
> >sender has to suffer some cost before it is
> >trusted to pay back some cost. Credit doesn't
> >need to degrade over time if the cost to the
> >sender of introducing credit doesn't degrade over time.
> >
> >Does this move us forward, or do you still
> >disagree? If so, I suggest a new thread would be useful.
> >
> >
> >This is probably correct, but I really don't think it belongs in A-M.
>
> [BB]: I don't think it should either. This is a
> discussion with Mirja, rather than a proposal for text.

I'll send a new main on crediting...

>
> >Except for the couple of items for more thought, dig in!
>
> Looking forward to the rest.
>
> CHeers
>
>
> Bob
>
> >Thanks,
> >--MM--
> >The best way to predict the future is to create it.  - Alan Kay
> >
> >Privacy matters!  We know from recent events
> >that people are using our services to speak in
> >defiance of unjust governments.   We treat
> >privacy and security as matters of life and
> >death, because for some users, they are.
>
> ________________________________________________________________
> Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT



--
-------------------------------------------------------------------
Dipl.-Ing. Mirja K=FChlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------


________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT

________________________________________________________________
Bob Briscoe,           &n= bsp;            =             &nbs= p;             BT --=====================_286535476==.ALT-- From bob.briscoe@bt.com Sat Jun 15 23:34:52 2013 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 7063021F93D4 for ; Sat, 15 Jun 2013 23:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHYO8lLttIig for ; Sat, 15 Jun 2013 23:34:45 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACBF21F9399 for ; Sat, 15 Jun 2013 23:34:45 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 16 Jun 2013 07:34:42 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Sun, 16 Jun 2013 07:34:41 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Sun, 16 Jun 2013 07:34:41 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r5G6Ya3v030553; Sun, 16 Jun 2013 07:34:37 +0100 Message-ID: <201306160634.r5G6Ya3v030553@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Jun 2013 07:34:35 +0100 To: Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: ConEx IETF list Subject: Re: [conex] Crediting [was: Re: Review of draft-ietf-conex-abstract-mech-06] 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: Sun, 16 Jun 2013 06:34:52 -0000 Mirja, At 16:03 09/06/2013, Mirja K=FChlewind wrote: >Hi, > >so back on this one: > > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meaning= of > > >credits is well enough specified here. My personal option is that= credits > > >should somehow get invalid (at some point in time). This is left open= in > > > the current text. > > > > > > > > >I think we need to agree before we can talk > > >about writing down what we agree... > > > > > > > > >I think that abstract-mech needs to embrace > > >*both*, explicitly if not implicitly. I need to > > >think about this some more, but I suspect that > > >it means we have unnecessarily over constrained audit here. > > > > [BB]: We need to allow multiple experiments at > > this experimental stage. But ultimately, sources > > will need to unambiuously know what Credit means, > > so they know how much to introduce and when. > >Yes, but we need to propose a mechanism when to send credits for the TCP= mod >draft and this means we need to have a common understanding how to handle >credits in the endsystem and the audit. I guess that's what standards are >good for. We might need a separate document for this. Not sure we are able= to >agree on this right now. As an alternative, I could also add some text in= the >TCP mod draft that the crediting is an open issue for experiments...? I would rather we supported diversity by stating=20 one concrete definition, and allowed experiments=20 with other definitions. But I would (naturally)=20 prefer my definition (ie credit lasts for as long=20 as a flow is active, and an auditor MAY time out=20 a flow after no less than 1 second of inactivity). Actually, I think this is the only concrete=20 definition on the table, unless you have a=20 proposal for exactly how to define your idea of credit gradually expiring. > > > > >Rather than thinking of Credit expiring after a > > >time, one can think of the combination of recent > > >Re-Echo signals and earlier Credit signals > > >keeping the Credit state fresh within a flow. As > > >long as you've sent Credit before a round of > > >congestion, then if you send Re-Echo afterwards > > >the Auditor can switch it round as if you sent > > >the Re-Echo before and the Credit after. > >I don't think this would change anything. Maybe make it even worse. As you >could also just send credit instead of ConEx marks That's not such a big problem, although I admit=20 it devalues the distinction between Credit &=20 Re-Echo, and I admit too that I don't have a solution to that. >and moreover there is >still no incentive to send further marks when you have build up a large >number of credits during Slow Start. My proposed definition of credit means that the sender wouldn't need to. It's not ideal from a network monitoring point of=20 view for the network to see such an anomalous=20 amount of credit and nothing to be able to=20 monitor recent actual congestion. But at least it=20 still provides full incentives against cheating. And, much more importantly, it also provides=20 incentives to slow-start more carefully (e.g.=20 watching the ACK timing to detect onset of=20 overshoot a round trip earlier), so that so much=20 credit isn't wasted. The Linux patch to do this=20 was too gentle, but the developers gave up=20 because at the time there was no way to reason=20 about how much less gentle it should be - ConEx provides that. > > > > > >So, when the Auditor holds Credit, it allows up > > >to that amount of Re-Echo to be considered as > > >having been sent before the congestion, rather > > >than after. Then, as it switches the Re-Echoes > > >back in time, it switches the Credits forward, so they always stay= recent. > > > > > >Credit is primarily a mechanism to ensure the > > >sender has to suffer some cost before it is > > >trusted to pay back some cost. Credit doesn't > > >need to degrade over time if the cost to the > > >sender of introducing credit doesn't degrade over time. > > > > > >Does this move us forward, or do you still > > >disagree? If so, I suggest a new thread would be useful. > >I have two concerns: >1) As mentioned above if a sender has sent a large number of credits during >Slow Start and causes only few congestion during the rest of the= transmission >(as today's TCP usually does), there is no incentive to send further ConEx >marks at all (neither credits nor loss/ECN ConEx marks). See above. >2) When sufficient markings has been sent during Slow Start, no further >credits should be needed. But if the audit for any reason will loose state >(e.g. because of memory restriction or a new audit is used due to= rerouting), >the sender will still not send new credits as will and thus will cause the >audit penalize the flow eventhough the sender did do nothing wrong. Audit would only lose state due to a re-route.*=20 Then, admittedly it would lose a load of credit,=20 but if the sender's flow was in progress, it=20 wouldn't need a huge repeat of credit again. Just=20 one, or perhaps two, ConEx re-echoes in response=20 to the ensuing audit losses would be sufficient to re-instate the audit= state. * =3D (If audit has mem restrictions it would not=20 have set the state in the first place.) > > > > > > > > >This is probably correct, but I really don't think it belongs in A-M. > >We might need an own document but there might also be some additional >requirements that should be added to this document. Going back on what I say below, I think it would=20 be better to state one full definition of credit=20 in abstr mech, just to be concrete, but then say=20 that if anyone prefers another definition, they=20 are encouraged to experiment with it and write up the outcome. > > > > [BB]: I don't think it should either. This is a > > discussion with Mirja, rather than a proposal for text. Tx again for you review. Bob ________________________________________________________________ Bob Briscoe, BT=20 From mirja.kuehlewind@ikr.uni-stuttgart.de Wed Jun 26 04:37:36 2013 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 0E13521F9F9F for ; Wed, 26 Jun 2013 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TWSbNXekgUA for ; Wed, 26 Jun 2013 04:37:32 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59421F9FB3 for ; Wed, 26 Jun 2013 04:37:31 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 706326020F; Wed, 26 Jun 2013 13:37:30 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 37A3F601F6; Wed, 26 Jun 2013 13:37:30 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe Date: Wed, 26 Jun 2013 13:37:29 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> <201306160634.r5G6Ya3v030553@bagheera.jungle.bt.co.uk> In-Reply-To: <201306160634.r5G6Ya3v030553@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201306261337.29853.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: ConEx IETF list Subject: Re: [conex] Crediting [was: Re: Review of draft-ietf-conex-abstract-mech-06] 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, 26 Jun 2013 11:37:36 -0000 Hi Bob, another definition could be: A credits gets invalid/is used when a new congestion signal (CE or loss)=20 arrives at the audit and the number of congestion-marked or lost packets=20 (red) is currently larger than ConEx-marked ones (black/purple). This would mean you potentially have to resend credits when congestion occu= rs. Mirja On Sunday 16 June 2013 08:34:35 Bob Briscoe wrote: > Mirja, > > At 16:03 09/06/2013, Mirja K=FChlewind wrote: > >Hi, > > > >so back on this one: > > > >9) Section 5.5.1 introdues the credit concept. Not sure if the meani= ng > > > > of credits is well enough specified here. My personal option is that > > > > credits should somehow get invalid (at some point in time). This is > > > > left open in the current text. > > > > > > > > > > > >I think we need to agree before we can talk > > > >about writing down what we agree... > > > > > > > > > > > >I think that abstract-mech needs to embrace > > > >*both*, explicitly if not implicitly. I need to > > > >think about this some more, but I suspect that > > > >it means we have unnecessarily over constrained audit here. > > > > > > [BB]: We need to allow multiple experiments at > > > this experimental stage. But ultimately, sources > > > will need to unambiuously know what Credit means, > > > so they know how much to introduce and when. > > > >Yes, but we need to propose a mechanism when to send credits for the TCP > > mod draft and this means we need to have a common understanding how to > > handle credits in the endsystem and the audit. I guess that's what > > standards are good for. We might need a separate document for this. Not > > sure we are able to agree on this right now. As an alternative, I could > > also add some text in the TCP mod draft that the crediting is an open > > issue for experiments...? > > I would rather we supported diversity by stating > one concrete definition, and allowed experiments > with other definitions. But I would (naturally) > prefer my definition (ie credit lasts for as long > as a flow is active, and an auditor MAY time out > a flow after no less than 1 second of inactivity). > > Actually, I think this is the only concrete > definition on the table, unless you have a > proposal for exactly how to define your idea of credit gradually expiring. > > > > >Rather than thinking of Credit expiring after a > > > >time, one can think of the combination of recent > > > >Re-Echo signals and earlier Credit signals > > > >keeping the Credit state fresh within a flow. As > > > >long as you've sent Credit before a round of > > > >congestion, then if you send Re-Echo afterwards > > > >the Auditor can switch it round as if you sent > > > >the Re-Echo before and the Credit after. > > > >I don't think this would change anything. Maybe make it even worse. As y= ou > >could also just send credit instead of ConEx marks > > That's not such a big problem, although I admit > it devalues the distinction between Credit & > Re-Echo, and I admit too that I don't have a solution to that. > > >and moreover there is > >still no incentive to send further marks when you have build up a large > >number of credits during Slow Start. > > My proposed definition of credit means that the sender wouldn't need to. > > It's not ideal from a network monitoring point of > view for the network to see such an anomalous > amount of credit and nothing to be able to > monitor recent actual congestion. But at least it > still provides full incentives against cheating. > > And, much more importantly, it also provides > incentives to slow-start more carefully (e.g. > watching the ACK timing to detect onset of > overshoot a round trip earlier), so that so much > credit isn't wasted. The Linux patch to do this > was too gentle, but the developers gave up > because at the time there was no way to reason > about how much less gentle it should be - ConEx provides that. > > > > >So, when the Auditor holds Credit, it allows up > > > >to that amount of Re-Echo to be considered as > > > >having been sent before the congestion, rather > > > >than after. Then, as it switches the Re-Echoes > > > >back in time, it switches the Credits forward, so they always stay > > > > recent. > > > > > > > >Credit is primarily a mechanism to ensure the > > > >sender has to suffer some cost before it is > > > >trusted to pay back some cost. Credit doesn't > > > >need to degrade over time if the cost to the > > > >sender of introducing credit doesn't degrade over time. > > > > > > > >Does this move us forward, or do you still > > > >disagree? If so, I suggest a new thread would be useful. > > > >I have two concerns: > >1) As mentioned above if a sender has sent a large number of credits > > during Slow Start and causes only few congestion during the rest of the > > transmission (as today's TCP usually does), there is no incentive to se= nd > > further ConEx marks at all (neither credits nor loss/ECN ConEx marks). > > See above. > > >2) When sufficient markings has been sent during Slow Start, no further > >credits should be needed. But if the audit for any reason will loose sta= te > >(e.g. because of memory restriction or a new audit is used due to > > rerouting), the sender will still not send new credits as will and thus > > will cause the audit penalize the flow eventhough the sender did do > > nothing wrong. > > Audit would only lose state due to a re-route.* > Then, admittedly it would lose a load of credit, > but if the sender's flow was in progress, it > wouldn't need a huge repeat of credit again. Just > one, or perhaps two, ConEx re-echoes in response > to the ensuing audit losses would be sufficient to re-instate the audit > state. > > * =3D (If audit has mem restrictions it would not > have set the state in the first place.) > > > > >This is probably correct, but I really don't think it belongs in A-M. > > > >We might need an own document but there might also be some additional > >requirements that should be added to this document. > > Going back on what I say below, I think it would > be better to state one full definition of credit > in abstr mech, just to be concrete, but then say > that if anyone prefers another definition, they > are encouraged to experiment with it and write up the outcome. > > > > [BB]: I don't think it should either. This is a > > > discussion with Mirja, rather than a proposal for text. > > Tx again for you review. > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------