From david.wagner@ikr.uni-stuttgart.de Tue Aug 27 02:34:04 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 1F8C721F9A4C for ; Tue, 27 Aug 2013 02:34:04 -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 XQ3ldutj4gPZ for ; Tue, 27 Aug 2013 02:34:00 -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 EF31421F9956 for ; Tue, 27 Aug 2013 02:33:59 -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 8120660081; Tue, 27 Aug 2013 11:33:58 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 42C5C60080; Tue, 27 Aug 2013 11:33:58 +0200 (CEST) From: David Wagner To: Bob Briscoe Date: Tue, 27 Aug 2013 11:33:57 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201307310233.56714.david.wagner@ikr.uni-stuttgart.de> <201307310757.r6V7v2lS016065@bagheera.jungle.bt.co.uk> In-Reply-To: <201307310757.r6V7v2lS016065@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Disposition: inline Organization: University of Stuttgart (Germany), IKR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308271133.57635.david.wagner@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: Tue, 27 Aug 2013 09:34:04 -0000 Hi Bob, *, the main point is that an audit implementing only the basic and simple criteria can be deceived for any definition of credit: a sender sending every packet with a credit mark will not be penalized for any of the discussed credit schemes. Therefore, in my opinion, auditing has to be defined to cover more than this minimum. Of course, auditing should still be as simple as possible, but counting marks only is just not sufficient. The surcharge definition separates the credit from the congestion re-echos. It basically introduces an additional signal because the ConEx marks keep their meaning and can't be substituted by credit. This increases the opportunities for auditing. One property of the surcharge scheme is that any aggregate of long lasting flows will show a balance of ConEx-marks (echoing loss or ECN-CE) and credit-marks. Unfortunately, short flows again disturb that nice picture. Generally, the possibility to audit aggregates can be desirable since it allows to implement "back pressure" not only on the actual source node but also on ISPs. ISPs could be motivated not to tolerate misbehaviour and maybe even to audit ingress traffic themselves, building up a chain of incentives for honest congestion exposure. In short, I think that the surcharge definition allows a better audit design than other options, nevertheless audit design guidelines are a crucial next step. David On Wednesday 31 July 2013 09:57:01 Bob Briscoe wrote: > David, > > What I'm missing before I can even understand anything you're saying > is a full definition of surcharge. As I said,... > > > the definition seems > > incomplete. It doesn't say anything about a penalty for having a > > negative balance of ECN or loss. > > > Bob > > At 01:33 31/07/2013, David Wagner wrote: > >Hi Bob, > > > >the surcharge approach does solve part of / shift the problem: > > > >of course the ecn-/loss-balance will get negative but the sender is > >supposed to have sent credit sufficient credit _in advance_ to cover > >that congestion event, thus making the credit counter remain > >non-negative after the congestion event. > >The point is, if there is no limit to replacing L-/E-marks by > >credit, _then_ there is not benefit / difference compared to the > >substitute approach (can also be seen at the penalty criteria). _If_ > >there is anything that verifies the observed loss and ECN-CE marks > >against the seen L- & E-marks, _then_ there is a benefit. E.g. the > >criterion#2. Or there also is a benefit if credits expire... > > > >So the resume remains, surcharge is not worse than substitute, and > >either the rtt-criterion or the expiration-approach should be > >applied in order improve it compared to substitute to ensure that > >credit really does not replace ConEx-marks. > >Or do _I_ miss something? > > > >David > > > > > > > > > >On Tuesday 30 July 2013 22:05:40 Bob Briscoe wrote: > > > David, Mirja, > > > > > > I've been worrying that the surcharge scheme doesn't work. Then I > > > re-read the definition of it in your draft, and the definition seems > > > incomplete. It doesn't say anything about a penalty for having a > > > negative balance of ECN or loss. > > > > > > The ECN or loss balances will go negative every congestion event > > > until ConEx markings balance them. Now I give a few options, because > > > I have to guess how you meant to define the scheme: > > > * If negative loss or ECN balance is penalised > > > o If a sufficient credit balance covers negativity of either loss > > > or ECN, then there is no need to re-balance loss or ECN with ConEx > > > re-echo marks, the sender can just send credit, which is the same > > > problem as subsitution. > > > o If credit does not cover negativity of loss or ECN, then > > what's it for? > > > * And if negative loss or ECN balance is not penalised, what is the > > > incentive to make them balance? > > > > > > As I said offlist before the ConEx meeting, I think the surcharge > > > scheme just conceals the same problem as the substitute scheme. > > > Without the definition of the scheme written down, I don't know > > > whether I'm being stupid and missing something obvious, or it's > > just broken. > > > > > > > > > Bob > > > > > > > > > At 18:23 15/07/2013, Bob Briscoe wrote: > > > >David, > > > > > > > >At 15:57 15/07/2013, David Wagner wrote: > > > >>Hi Bob, > > > >> > > > >>On Monday 15 July 2013 13:32:25 Bob Briscoe wrote: > > > >> > David, > > > >> > > > > >> > At 18:44 10/06/2013, David Wagner wrote: > > > >> > >Anyway, I don't yet have a good credit concept. > > > >> > > > > >> > Yes, this is a problem. > > > >>I think this is a fundamental one since it questions the > > > >>credibility of ConEx info and thus the incentive to deploy it. > > > > > > > >Yes, in as much as every part of a security system is fundamental, > > > >just as every one of the four walls around a castle is fundamental. > > > > > > > >> > >Which also needs to address handling loss of ConEx-marked packets, > > > >> > >at the sender and at the audit. > > > >> > > > > >> > I don't think of that as a problem. I may not have covered it at the > > > >> > IETF, but I think I did in my PhD thesis. > > > >>oops, I didn't check that. > > > > > > > >S.7.4.4 & 7.4.5 > > > > > > > > > > > >>I wrote some sentences on it in the discussion draft, mainly coming > > > >>to the conclusion that an auditor could estimate average loss of > > > >>connection, thus providing an upper bound for loss of > > Conex-marked packets. > > > > > > > >I made it the responsibility of the sender to repair (it can know if > > > >a packet it marked as re-echoed was lost). > > > > > > > > > > > >>Anyway, I'd really like to discuss ConEx crediting further. > > > > > > > >Yes, I'm sure the chairs will be making this a subject for > > > >discussion in Berlin. And I'll try to comment on your draft on the > > > >list if I get to it before then. > > > > > > > >Cheers > > > > > > > > > > > > > > > >Bob > > > > > > > > > > > >>David > > > >> > > > > >> > > > > >> > > > > >> > Bob > > > >> > > > > >> > > > > >> > >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 > > > >> > >------------------------------------------------------------------- > > > >> > > > > >> > ________________________________________________________________ > > > >> > Bob Briscoe, BT > > > >> > > > > >> > > > > > > > > >________________________________________________________________ > > > >Bob Briscoe, BT > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT > > > > > > > > > > > >-- > >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 > >------------------------------------------------------------------- > > ________________________________________________________________ > Bob Briscoe, BT > > From marcelo@it.uc3m.es Tue Aug 27 12:28:07 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 C70A721F9AE3 for ; Tue, 27 Aug 2013 12:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KahStiBe6gaA for ; Tue, 27 Aug 2013 12:28:03 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5CC21F9B0E for ; Tue, 27 Aug 2013 12:28:02 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 63123CD5567 for ; Tue, 27 Aug 2013 21:27:59 +0200 (CEST) X-uc3m-safe: yes Received: from [163.117.203.192] (unknown [163.117.203.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id BF0EBCD555B for ; Tue, 27 Aug 2013 21:27:58 +0200 (CEST) Message-ID: <521CFDC0.7070607@it.uc3m.es> Date: Tue, 27 Aug 2013 21:28:00 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: 'ConEx IETF list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 138 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Tue, 27 Aug 2013 21:27:59 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20110.001 Subject: [conex] draft minutes posted 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, 27 Aug 2013 19:28:07 -0000 You can find them here: http://www.ietf.org/proceedings/87/minutes/minutes-87-conex Thanks Dirk for taking the notes!! If you have comments, let me know. Regards, marcelo From mattmathis@google.com Tue Aug 27 13:46:28 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 078AD11E81F8 for ; Tue, 27 Aug 2013 13:46:28 -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 hqZp8RHiCh+x for ; Tue, 27 Aug 2013 13:46:27 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1DC11E81EC for ; Tue, 27 Aug 2013 13:46:27 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k18so600801qcv.41 for ; Tue, 27 Aug 2013 13:46:26 -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=rthrX2t+EOnUAJjzixAVLN2sfVP/uXUUhelTPQ5UxQU=; b=SKj1Rf9boW+x6BnU4t9TkA1WQXqfe6TUwaRYHq+Gzi3cacm/OMj162b1mctxAKrWDj 2ruWmw5LWk7DqjjEvnftx+pbOEyxUXdA19+trhHOb/ivz0A20nT4RtLxH7AkBwb7OEyu gkMY5Vd5fukdLc8kbnZITvKN8g6WGO2Zeo9gHzuJlyw2sG5xPNhlC7/SnTvuEayT/+kf l1A37tlTImRLEbsqc9UjLJsOoakJ2pQEHnuy9UTn7ZuqRqcD/w3lsMerVEc18P7LMq+t M9Ky8MeXAGYySajWl5ytdaJqPLomH7lxKexqCBgHDAGawBxvMGp39KsTh0EJQfewCdFd +JJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rthrX2t+EOnUAJjzixAVLN2sfVP/uXUUhelTPQ5UxQU=; b=jaqYqKNcsayZR+TkyR3fdoMhM5T2JheoanU7Ut23hQKqZAiQx5Dgq3/BeSHAKX8XBq f2l8XHSmVnN1l7754jc+vf8GB1uqK0v8waPDi9uieEHWpuIVZ/swWS9Pgxht0+mA0Cnp nlOsH0X8ENR+uzH7eZB8eq9sntXS3gTQA7fp1JHIDl4sLa1mjIppgikhqkcej80i1TOD 1TAQioDRsEr1gkykmbD7s20ntaX7y/Afv2JxgxBGH8tqRXOpav48R4vU4VuvxsUGo1hB kZKus4eFNdXYN2ZG12r3RFsN5cQHam/XDJjdkMJ4FZH9i5bM4XxHSsgNWT657VBUUI/6 i80g== X-Gm-Message-State: ALoCoQkC8lLOU8mwcCEP/kmrGucoB8YzLgz3y3zijQ162xFOYP65jicQ3lg4qt+Y1oE1c8i8hrawsss2mvevPYGyEkvCOI1FgCdY21D0dXQ8Aqi0qB/Rr8umHGlIqI3EWReh5i3ap708m90kPf21hSpNaPJ3oCDaIS8AhlYXBcI2gY1tthe9T9DfCMNlECIxQQNa0/MUFdnN MIME-Version: 1.0 X-Received: by 10.49.39.39 with SMTP id m7mr26084111qek.60.1377636386762; Tue, 27 Aug 2013 13:46:26 -0700 (PDT) Received: by 10.229.171.2 with HTTP; Tue, 27 Aug 2013 13:46:26 -0700 (PDT) In-Reply-To: <201308271133.57635.david.wagner@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201307310233.56714.david.wagner@ikr.uni-stuttgart.de> <201307310757.r6V7v2lS016065@bagheera.jungle.bt.co.uk> <201308271133.57635.david.wagner@ikr.uni-stuttgart.de> Date: Tue, 27 Aug 2013 13:46:26 -0700 Message-ID: From: Matt Mathis To: David Wagner Content-Type: multipart/alternative; boundary=047d7bdc156476958104e4f3f74f 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: Tue, 27 Aug 2013 20:46:28 -0000 --047d7bdc156476958104e4f3f74f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 27, 2013 at 2:33 AM, David Wagner < david.wagner@ikr.uni-stuttgart.de> wrote: > the main point is that an audit implementing only the basic and simple > criteria can be deceived for any definition of credit: > a sender sending every packet with a credit mark will not be penalized for > any of the discussed credit schemes. > There is something fundamental missing from this conversation. The above scenario is tantamount to exaggerating your resource consumption. It is not necessarily a bug that the audit function overlooks errors with this sign. Note that this signal is also being used by some policy device which has its own (but unspecified) response to consuming resources. Even though the policy device is not fully specified, I would predict that it is not to your advantage to claim to use more resources than you actually do. 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. --047d7bdc156476958104e4f3f74f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Aug 27, 2013 at 2:33 AM, David Wagner <david.wagne= r@ikr.uni-stuttgart.de> wrote:
t= he main point is that an audit implementing only the basic and simple crite= ria can be deceived for any definition of credit:
a sender sending every packet with a credit mark will not be penalized for = any of the discussed credit schemes.

There is s= omething fundamental missing from this conversation. =A0The above scenario = is tantamount to exaggerating your resource consumption. =A0It is not neces= sarily a bug that the audit function overlooks errors with this sign. =A0 N= ote that this signal is also being used by some policy device which has its= own (but unspecified) response to consuming resources.

Even though= the policy device is not fully specified, I would predict that it is not t= o your advantage to claim to use more resources than you actually do.

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

Privacy matters! =A0We know from recen= t 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.
--047d7bdc156476958104e4f3f74f-- From david.wagner@ikr.uni-stuttgart.de Wed Aug 28 05:13: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 9D78511E8132 for ; Wed, 28 Aug 2013 05:13: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 Y9lrJknzoT+o for ; Wed, 28 Aug 2013 05:13: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 400FE11E8165 for ; Wed, 28 Aug 2013 05:13: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 B9A92600C3; Wed, 28 Aug 2013 14:13:30 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A9A29600C1; Wed, 28 Aug 2013 14:13:30 +0200 (CEST) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: Matt Mathis Date: Wed, 28 Aug 2013 14:13:29 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201308271133.57635.david.wagner@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201308281413.29910.david.wagner@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, 28 Aug 2013 12:13:36 -0000 Hi, these issues are not purely technical, they also depend on our expectations on the future ConEx-enabled Internet. On Tuesday 27 August 2013 22:46:26 Matt Mathis wrote: > On Tue, Aug 27, 2013 at 2:33 AM, David Wagner < > david.wagner@ikr.uni-stuttgart.de> wrote: > > > the main point is that an audit implementing only the basic and simple > > criteria can be deceived for any definition of credit: > > a sender sending every packet with a credit mark will not be penalized for > > any of the discussed credit schemes. > > > > There is something fundamental missing from this conversation. The above > scenario is tantamount to exaggerating your resource consumption. It is In my opinion, auditing must not be applied to all flows and, not the same (sophisticated) algorithm must be applied in all audits. Just like traffic enforcement cameras in road traffic: the probality of auditing and its penalty just has to be scaring enough. Because limited penalties in ConEx audits we'd need a higher density than on the streets, yes. > not necessarily a bug that the audit function overlooks errors with this > sign. Note that this signal is also being used by some policy device > which has its own (but unspecified) response to consuming resources. Right, if policing and auditing is applied to a flow, they induce converse incentives, hopefully leading to purely honest congestion exposure. But, in my opinion, auditing should not rely on the existence (and proper function) of any policing in that alien sender's domain. And if policing is applied, it bases on the assumption that there is an audit ensuring that the ConEx signaling (regarding congestion, not congestion+credit) is correct... > > Even though the policy device is not fully specified, I would predict that > it is not to your advantage to claim to use more resources than you > actually do. The meaning of credit is difficult, but not actual resource usage. It's more like a warning, announcing that the sender is risking congestion. Therefore, for many policing intentions, policing would rely on congestion marks only, not on credit (again: I would expect it to do so...). All in all, I think we should aim at designing an as robust as possible audit algorithm, maybe accompanied with more lightweight alternatives. David > > 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. > -- 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 -------------------------------------------------------------------