From marcelo@it.uc3m.es Tue Jul 2 12:13:39 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 0B46121F9AFA for ; Tue, 2 Jul 2013 12:13:39 -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 IPttvHFomh0e for ; Tue, 2 Jul 2013 12:13:33 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D63B511E80EC for ; Tue, 2 Jul 2013 12:13:30 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 092E7CD6064 for ; Tue, 2 Jul 2013 21:13:29 +0200 (CEST) X-uc3m-safe: yes Received: from [10.0.1.2] (43.120.220.87.dynamic.jazztel.es [87.220.120.43]) (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 DE11ACD5E9F for ; Tue, 2 Jul 2013 21:13:28 +0200 (CEST) Message-ID: <51D32657.3040109@it.uc3m.es> Date: Tue, 02 Jul 2013 21:13:27 +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 succeeded SMTP AUTHACL 141 matched, not delayed by milter-greylist-4.2.7 (smtp01.uc3m.es); Tue, 02 Jul 2013 21:13:28 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19990.001 Subject: [conex] Slots for next meeting in berlin 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, 02 Jul 2013 19:13:39 -0000 Hi, Conex will meet in the next meeting in berlin. If you want a slot, please send me an email. Regards, marcelo From mirja.kuehlewind@ikr.uni-stuttgart.de Thu Jul 4 10:42:25 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 1D88121F9E5F for ; Thu, 4 Jul 2013 10:42:25 -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 UEJGcZybcvIN for ; Thu, 4 Jul 2013 10:42:20 -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 C709A21F9E54 for ; Thu, 4 Jul 2013 10:42:19 -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 6FBD760219; Thu, 4 Jul 2013 19:42:18 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 5DADB60218; Thu, 4 Jul 2013 19:42:18 +0200 (CEST) From: Mirja =?iso-8859-1?q?K=FChlewind?= To: jiyengar@fandm.edu Date: Thu, 4 Jul 2013 19:42:17 +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: 7bit Content-Disposition: inline Message-Id: <201307041942.17867.mkuehle@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: Thu, 04 Jul 2013 17:42:25 -0000 Hi Jana, I'm incorporating your feedback at the moment. I commet on those things below, I did not take over as suggest. (That means the other things I removed in this mail as integrated as proposed). See below... > - 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." I wanted to have the statement a little stronger, basically saying that ConEx is only with the more accurate ECN really usable. I changed the paragraph to the following text: "While loss-based congestion feedback should be minimized, ECN could actually provide more fine-grained feedback information. ConEx-based traffic measurement or management mechanisms would benefit from this. Unfortunately the current ECN does not reflect multiple congestion markings which occur within the same Round-Trip Time (RTT). A more accurate feedback extension to ECN is defined in a separate document [draft-kuehlewind-tcpm-accurate-ecn], as this is also useful for other mechanisms." > 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. We really wanted to have a MUST here, as we want (modern) system that implement ConEx to also implement SACK and ECN. Only because they try to negotiate, it does mean, that the other end will support it though. We could discuss that we want a "MUST negotiate for SACK" and "SHOULD negotiate for ECN" because SACK really helps to increase the accuracy. But I actually see no reason to only have a SHOULD for ECN. > - "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. I changed this to "A ConEx sender MUST expose all congestion information..." because that was the idea. If you decide to use ConEx, of course, you are planning send some ConEx markings from time to time, but actually the point is that you have to reflect ALL congestion information. Does this make more sense for you? > Perhaps cite the > v6 options draft here without specifying here what a Conex sender MUST do. Sorry, don't get this...? > - "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. I cited draft-ietf-tsvwg-byte-pkt-congest for the lower bullet point. But the reasoning for the upper point is mainly, that this document must specify one of the two ways, and we decided to handle the information byte-wise because that's how there are usually available in TCP (ack'ed bytes). Do I need to reason this? > 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? This would be a sender-only change to get more accurate ECN information. Of course its complex and there is still a risk of missing congestion information, but we decided to describe this option here, as ConEx with 'classic' ECN is hardly usable. > > 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 differently > sized segments, and even combine retransmitted bytes with new bytes within > a segment. This assumption is not critical, and so I would suggest dropping > it from the text. This should say, that the described solution can only be used under the assumption that packets are equally sized (which is at least true for e.g. file transfers with full IP packets). I added some more text in the introduction part of section 3 'Congestion Accounting' to explain that the number of (lost/marked) packets needs to be estimated otherwise: "Otherwise if this is not the case and a sender sends different sized packets (with unequally distributed packet sizes), the sender needs to memorize or estimate the number of ECN-marked or lost packets. A sender might be able to reconstruct the number of packets and thus the header bytes if the packet sizes of the last RTT are known. Otherwise if no additional information is available the worst case number of headers should be estimated in a conservative way based on a minimum packet size (of all packets sent in the last RTT). If the number of ConEx marked packets is smaller (or larger) than the estimated number of ECN-marked or lost packets, the additional header bytes should the added to (or can be subtracted from) the respective counter." Does this help? Thanks a lot for the review! Mirja From david.wagner@ikr.uni-stuttgart.de Fri Jul 12 03:02: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 0AF8321F9D9E for ; Fri, 12 Jul 2013 03:02: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 YYVtYlDZO-HO for ; Fri, 12 Jul 2013 03:02: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 51B6D21F9D9C for ; Fri, 12 Jul 2013 03:02:00 -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 A92BD60294 for ; Fri, 12 Jul 2013 12:01: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 A2B7A6011D for ; Fri, 12 Jul 2013 12:01:58 +0200 (CEST) From: David Wagner To: conex@ietf.org Date: Fri, 12 Jul 2013 12:01:58 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) MIME-Version: 1.0 Organization: University of Stuttgart (Germany), IKR Content-Type: Multipart/Mixed; boundary="Boundary-00=_WQ93Rr2UFhZ1mRJ" Message-Id: <201307121201.58082.david.wagner@ikr.uni-stuttgart.de> Subject: [conex] Fwd: New Version Notification for draft-wagner-conex-credit-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:02:13 -0000 --Boundary-00=_WQ93Rr2UFhZ1mRJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, we submitted a new draft describing potential definitions of credit and credit handling in the audit. This is meant as basis for discussion and we would appreciate feedback, hopefully leading to final definition of credit in the abstract-mech document soon. David and Mirja --Boundary-00=_WQ93Rr2UFhZ1mRJ Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: internet-drafts@ietf.org: New Version Notification for draft-wagner-conex-credit-00.txt Content-Disposition: inline Return-Path: X-Original-To: david.wagner@ikr.uni-stuttgart.de Delivered-To: david.wagner@ikr.uni-stuttgart.de Received: from hydra.rus.uni-stuttgart.de (hydra.rus.uni-stuttgart.de [129.69.1.55]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 86AFA60294; Fri, 12 Jul 2013 12:00:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by hydra.rus.uni-stuttgart.de (Postfix) with ESMTP id 7B4CD12B739; Fri, 12 Jul 2013 12:00:27 +0200 (CEST) X-Relay-Countries: US ** US XX X-Virus-Scanned: by amavisd-new at hydra.rus.uni-stuttgart.de X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.303, SA2DNSBLC=0.001, SPF_PASS=-0.001] autolearn=no Received: from hydra.rus.uni-stuttgart.de ([127.0.0.1]) by localhost (hydra.rus.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njjsSjQombHh; Fri, 12 Jul 2013 12:00:26 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by hydra.rus.uni-stuttgart.de (Postfix) with ESMTP; Fri, 12 Jul 2013 12:00:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A72621F9702; Fri, 12 Jul 2013 02:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 1a6H-SkyuXEa; Fri, 12 Jul 2013 02:58:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E34B421F9AF1; Fri, 12 Jul 2013 02:58:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: David Wagner , Mirja Kuehlewind Subject: New Version Notification for draft-wagner-conex-credit-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712095823.27791.14354.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 02:58:23 -0700 A new version of I-D, draft-wagner-conex-credit-00.txt has been successfully submitted by David Wagner and posted to the IETF repository. Filename: draft-wagner-conex-credit Revision: 00 Title: ConEx Crediting and Auditing Creation date: 2013-07-12 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-wagner-conex-cre= dit-00.txt Status: http://datatracker.ietf.org/doc/draft-wagner-conex-credit Htmlized: http://tools.ietf.org/html/draft-wagner-conex-credit-00 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. In order to make ConEx information useful, reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. However, there is always a delay between congestion events and the respective ConEx signal at the audit. To avoid state and complex Round-Trip Time estimations at the audit, in [draft-ietf-conex-abstract-mech] it is proposed to use credit signals sent in advance to cover potential congestion in the next feedback delay duration. Unfortunately, introducing credit does not provide incentives to honestly report congestion. This document lists potential issues regarding the proposed crediting and discusses potential solutions approaches to interpret and handle credits at the audit. = = The IETF Secretariat --Boundary-00=_WQ93Rr2UFhZ1mRJ-- From john@jlc.net Fri Jul 12 03:44:23 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 44B4521F9DB2 for ; Fri, 12 Jul 2013 03:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.135 X-Spam-Level: X-Spam-Status: No, score=-106.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 5PbHZMx1ewlZ for ; Fri, 12 Jul 2013 03:44:18 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0D21F9DB0 for ; Fri, 12 Jul 2013 03:44:18 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D5CA833C20; Fri, 12 Jul 2013 06:44:17 -0400 (EDT) Date: Fri, 12 Jul 2013 06:44:17 -0400 From: John Leslie To: David Wagner Message-ID: <20130712104417.GO18393@verdi> References: <201307121201.58082.david.wagner@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201307121201.58082.david.wagner@ikr.uni-stuttgart.de> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] Fwd: New Version Notification for draft-wagner-conex-credit-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 10:44:23 -0000 David Wagner wrote: > > we submitted a new draft describing potential definitions of credit > and credit handling in the audit. This strikes me as a good idea -- there has been confusion about that, and having a separate draft will probably aid discussion here. > Abstract: Let me comment on the Abstract before I read the whole draft... > Congestion Exposure (ConEx) is a mechanism by which senders inform > the network about the congestion encountered by previous packets on > the same flow. This indeed is the way we define ConEx. > In order to make ConEx information useful, reliable auditing is > necessary to provide a strong incentive to declare ConEx > information honestly. I personally disagree with this statement. (I'd be happy to go into why I disagree; but I don't think this is the right email to do so.) > However, there is always a delay between congestion events and > the respective ConEx signal at the audit. To avoid state and > complex Round-Trip Time estimations at the audit, in > [draft-ietf-conex-abstract-mech] it is proposed to use credit signals > sent in advance to cover potential congestion in the next feedback > delay duration. Unfortunately, introducing credit does not provide > incentives to honestly report congestion. This document lists > potential issues regarding the proposed crediting and discusses > potential solutions approaches to interpret and handle credits at the > audit. That text belongs in an Introduction. IMHO, the Abstract should limit itself to something like: " " The ConEx Working Group is designing an audit mechanism to test " whether congestion encountered is being honestly reported by the " sender. This mechanism involves "credit" markings for possible " congestion not yet encountered. This document discusses issues " regarding such credit markings. -- John Leslie From bob.briscoe@bt.com Mon Jul 15 04:20:42 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 45C8211E80D1 for ; Mon, 15 Jul 2013 04:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 TnsmnlkOii1w for ; Mon, 15 Jul 2013 04:20:36 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEEE11E80CC for ; Mon, 15 Jul 2013 04:20:36 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 12:20:34 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 12:20:33 +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; Mon, 15 Jul 2013 12:20:29 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.132.246]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6FBKRjk011064; Mon, 15 Jul 2013 12:20:28 +0100 Message-ID: <201307151120.r6FBKRjk011064@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jul 2013 12:19:08 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201306261337.29853.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306091703.33933.mkuehle@ikr.uni-stuttgart.de> <201306160634.r5G6Ya3v030553@bagheera.jungle.bt.co.uk> <201306261337.29853.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] 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, 15 Jul 2013 11:20:42 -0000 Mirja, Sorry for being unresponsive on this thread at the time. Inline... (I'll reply separately where nec. to earlier postings from others too.) At 12:37 26/06/2013, Mirja Kuehlewind wrote: >Hi Bob, > >another definition could be: > >A credits gets invalid/is used when a new congestion signal (CE or loss) >arrives at the audit and the number of congestion-marked or lost packets >(red) is currently larger than ConEx-marked ones (black/purple). > >This would mean you potentially have to resend credits when congestion= occurs. I think what you're saying is that when a credit=20 needs to be used, it is used for ever, even if=20 later a re-echo makes it up. So the re-echoes gradually replace the credit. IMO that doesn't work either. During a=20 long-running flow, the sender will always re-echo=20 after the associated congestion. So it always=20 needs a round-trip worth of credit to save its=20 flow from being hit by the auditor. If all credit=20 is invalidated whenever it is used, then, in=20 steady state, every time the sender re-echoes it=20 will also have to send an equal amount of credit.=20 THat doubles the 'cost'. Actually, all the sender=20 will do is send credit and not re-echo. This is a hard dilemma isn't it? I will try to state it here: There are two opposing requirements: 1) We want the sender to have to send sufficient=20 credit to cover the large amount of harm it might=20 cause due to a slow-start overshoot. But we don't=20 want the sender to know that it can just get that=20 credit back again if it ends up not being needed.=20 Otherwise, after a short flow, it might as well=20 keep sending even dummy traffic just to use up=20 the spare credit. And if it has traffic to send,=20 it can cause congestion without any more 'cost'.=20 That would be like getting your insurance premium=20 back at the end of the year if you hadn't claimed=20 - it would not cover the risks with other=20 people's QoE that you took by doing slow-start. This implies credit should expire over time. 2) However, during a long-running flow, we don't=20 want credit to expire, because the sender needs=20 it to hold back any penalty for one round trip,=20 for every little congestion event. Bob >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= 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 > > 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= you > > >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= 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.* > > 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 > > > >-- >------------------------------------------------------------------- >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 bob.briscoe@bt.com Mon Jul 15 04:32: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 C951B11E80D7 for ; Mon, 15 Jul 2013 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 Dn5mug4lx5e5 for ; Mon, 15 Jul 2013 04:32:33 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id A757421F9E6A for ; Mon, 15 Jul 2013 04:32:32 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 12:32:25 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Jul 2013 12:32:29 +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; Mon, 15 Jul 2013 12:32:27 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.132.246]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6FBWPsT011095; Mon, 15 Jul 2013 12:32:26 +0100 Message-ID: <201307151132.r6FBWPsT011095@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jul 2013 12:32:25 +0100 To: David Wagner From: Bob Briscoe In-Reply-To: <201306101944.38261.david.wagner@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> <201306101944.38261.david.wagner@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: conex@ietf.org 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, 15 Jul 2013 11:32:37 -0000 David, I ought to read your credit draft first, but I'll just quickly respond here (altho nothing much additional worth saying I'm afraid), ... At 18:44 10/06/2013, David Wagner wrote: >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. This doesn't really "avoid problems". It just means the auditor knows it has a problem for a certain period. >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. That's not an argument for time-degrading credit, you're just saying it's likely. It is likely if there's an argument for it, and it's not likely if there isn't. >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? We want the amount of credit to reflect the risk of cost to others. (See my point in the email to Mirja about the perverse incentives that would arise if you knew you would get your insurance premiums back if you hadn't made a claim by the end of the year. Then it would no longer be insurance, it would be an accident damage pre-payment account.) But we also have the dilemma I outlined in the mail to Mirja. >Anyway, I don't yet have a good credit concept. Yes, this is a problem. >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. 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 From david.wagner@ikr.uni-stuttgart.de Mon Jul 15 07:50:12 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 9282821E808C for ; Mon, 15 Jul 2013 07:50:12 -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 Ya-HTw7Y4TMV for ; Mon, 15 Jul 2013 07:50:07 -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 4AA8921F9D62 for ; Mon, 15 Jul 2013 07:50:06 -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 B4B1E602F0; Mon, 15 Jul 2013 16:50:05 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id AD4B3601CD; Mon, 15 Jul 2013 16:50:05 +0200 (CEST) From: David Wagner To: John Leslie Date: Mon, 15 Jul 2013 16:50:04 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201307121201.58082.david.wagner@ikr.uni-stuttgart.de> <20130712104417.GO18393@verdi> In-Reply-To: <20130712104417.GO18393@verdi> X-KMail-QuotePrefix: > Organization: University of Stuttgart (Germany), IKR MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201307151650.04974.david.wagner@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] Fwd: New Version Notification for draft-wagner-conex-credit-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:50:12 -0000 Hi John, thanks for your comment, I will take it into account. Less might be better in the abstract, but I'd like to have the audit mentioned already here. What don't you like in the motivation for ConEx auditing? I'd also like to hear your comments on the ConEx crediting alternatives themselves. Or your solution. David On Friday 12 July 2013 12:44:17 John Leslie wrote: > David Wagner wrote: > > > > we submitted a new draft describing potential definitions of credit > > and credit handling in the audit. > > This strikes me as a good idea -- there has been confusion about that, > and having a separate draft will probably aid discussion here. > > > Abstract: > > Let me comment on the Abstract before I read the whole draft... > > > Congestion Exposure (ConEx) is a mechanism by which senders inform > > the network about the congestion encountered by previous packets on > > the same flow. > > This indeed is the way we define ConEx. > > > In order to make ConEx information useful, reliable auditing is > > necessary to provide a strong incentive to declare ConEx > > information honestly. > > I personally disagree with this statement. (I'd be happy to go into > why I disagree; but I don't think this is the right email to do so.) > > > However, there is always a delay between congestion events and > > the respective ConEx signal at the audit. To avoid state and > > complex Round-Trip Time estimations at the audit, in > > [draft-ietf-conex-abstract-mech] it is proposed to use credit signals > > sent in advance to cover potential congestion in the next feedback > > delay duration. Unfortunately, introducing credit does not provide > > incentives to honestly report congestion. This document lists > > potential issues regarding the proposed crediting and discusses > > potential solutions approaches to interpret and handle credits at the > > audit. > > That text belongs in an Introduction. > > IMHO, the Abstract should limit itself to something like: > " > " The ConEx Working Group is designing an audit mechanism to test > " whether congestion encountered is being honestly reported by the > " sender. This mechanism involves "credit" markings for possible > " congestion not yet encountered. This document discusses issues > " regarding such credit markings. > > -- > John Leslie > From david.wagner@ikr.uni-stuttgart.de Mon Jul 15 07:57: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 B31CA21F9E26 for ; Mon, 15 Jul 2013 07:57:07 -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 SAo+CFjvdaZN for ; Mon, 15 Jul 2013 07:57: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 98F9621F9DAF for ; Mon, 15 Jul 2013 07:57: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 F2503602F5; Mon, 15 Jul 2013 16:57:02 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id EAFEF601CD; Mon, 15 Jul 2013 16:57:02 +0200 (CEST) From: David Wagner To: Bob Briscoe Date: Mon, 15 Jul 2013 16:57:02 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306101944.38261.david.wagner@ikr.uni-stuttgart.de> <201307151132.r6FBWPsT011095@bagheera.jungle.bt.co.uk> In-Reply-To: <201307151132.r6FBWPsT011095@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > Organization: University of Stuttgart (Germany), IKR MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201307151657.02177.david.wagner@ikr.uni-stuttgart.de> Cc: conex@ietf.org 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, 15 Jul 2013 14:57:07 -0000 Hi Bob, On Monday 15 July 2013 13:32:25 Bob Briscoe wrote: > David, > > I ought to read your credit draft first, but I'll just quickly > respond here (altho nothing much additional worth saying I'm afraid), ... > > At 18:44 10/06/2013, David Wagner wrote: > >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. > > This doesn't really "avoid problems". It just means the auditor knows > it has a problem for a certain period. Well, that might be enough anyway. If the auditor knows it shouldn't penalize flows for a certain destination network for the time x, auditing could still cover most of the traffic and thus still be effective. > > >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. > > That's not an argument for time-degrading credit, you're just saying > it's likely. It is likely if there's an argument for it, and it's not > likely if there isn't. Agreed. But there are other & stronger arguments in favor of time-degrading / expiring credits. > > >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? > > We want the amount of credit to reflect the risk of cost to others. > (See my point in the email to Mirja about the perverse incentives > that would arise if you knew you would get your insurance premiums > back if you hadn't made a claim by the end of the year. Then it would > no longer be insurance, it would be an accident damage pre-payment > account.) But we also have the dilemma I outlined in the mail to Mirja. > > > >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. > > >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. 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. Anyway, I'd really like to discuss ConEx crediting further. 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 > > From internet-drafts@ietf.org Mon Jul 15 08:49: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 60CA721E80B3; Mon, 15 Jul 2013 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 gJVfOqHgdc41; Mon, 15 Jul 2013 08:49:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC1D21E80B5; Mon, 15 Jul 2013 08:49:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715154923.6769.77027.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 08:49:23 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-04.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:49:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : TCP modifications for Congestion Exposure Author(s) : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-04.txt Pages : 14 Date : 2013-07-15 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-tcp-modifications-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bob.briscoe@bt.com Mon Jul 15 10:24:01 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 D9C4D11E8105 for ; Mon, 15 Jul 2013 10:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 UJx7XFOBNLKh for ; Mon, 15 Jul 2013 10:23:57 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF2011E80AD for ; Mon, 15 Jul 2013 10:23:51 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 18:23:48 +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; Mon, 15 Jul 2013 18:23:49 +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; Mon, 15 Jul 2013 18:23:44 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.124.45]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6FHNgxb012046; Mon, 15 Jul 2013 18:23:43 +0100 Message-ID: <201307151723.r6FHNgxb012046@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jul 2013 18:23:39 +0100 To: David Wagner From: Bob Briscoe In-Reply-To: <201307151657.02177.david.wagner@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306101944.38261.david.wagner@ikr.uni-stuttgart.de> <201307151132.r6FBWPsT011095@bagheera.jungle.bt.co.uk> <201307151657.02177.david.wagner@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: conex@ietf.org 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, 15 Jul 2013 17:24:02 -0000 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 From internet-drafts@ietf.org Mon Jul 15 14:00:34 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 0302621E817B; Mon, 15 Jul 2013 14:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 rXC1S2cVZ9NM; Mon, 15 Jul 2013 14:00:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 764EE21E8098; Mon, 15 Jul 2013 14:00:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715210033.4377.30872.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:00:33 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-mobile-02.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:00:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : Mobile Communication Congestion Exposure Scenario Author(s) : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-02.txt Pages : 23 Date : 2013-07-15 Abstract: This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-mobile-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-mobile-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 15:38:38 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 6569C11E8243; Mon, 15 Jul 2013 15:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 N6Ny2deupiOP; Mon, 15 Jul 2013 15:38:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A2311E824F; Mon, 15 Jul 2013 15:38:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715223837.19332.61346.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:38:37 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-07.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:38:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the = IETF. Title : Congestion Exposure (ConEx) Concepts and Abstract Mechan= ism Author(s) : Matt Mathis Bob Briscoe Filename : draft-ietf-conex-abstract-mech-07.txt Pages : 28 Date : 2013-07-15 Abstract: This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-abstract-mech-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bob.briscoe@bt.com Mon Jul 15 15:54: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 A688D11E81E3 for ; Mon, 15 Jul 2013 15:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Cwa0zbp8vjeP for ; Mon, 15 Jul 2013 15:54:08 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF6411E81D5 for ; Mon, 15 Jul 2013 15:54:07 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 23:53:59 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Jul 2013 23:54:01 +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; Mon, 15 Jul 2013 23:54:00 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.124.66]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6FMrwDW012841; Mon, 15 Jul 2013 23:53:58 +0100 Message-ID: <201307152253.r6FMrwDW012841@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Jul 2013 23:53:57 +0100 To: ConEx IETF list , Mirja KUEHLEWIND , Marcelo BAGNULO BRAUN From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [conex] Fwd: New Version Notification for draft-ietf-conex-abstract-mech-07.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:54:13 -0000 ConEx list, Marcelo, Mirja, Matt & I just posted an -07 update to the conex-abstract-mech draft. The changes addressed all of Mirja's review comments that have been being discussed recently. See the diff link below. Thanks for these, Mirja - all very useful. We managed to tie up all outstanding issues in this document (AFAWCT). The credit issue is still open, but we have defined that as an issue for the specific ConEx encoding doc, not this abstract one. If the chairs agree with this approach, we can get this one moving through the process while the WG works on the remaining chartered docs. This may seem a fudge, but it isn't. abstract-mech was written specifically to define an abstraction: to identify the areas where there is flexibility, not to close off flexibility. Bob (& Matt) >From: >To: Bob Briscoe , "Bob J.Briscoe" , > "Matt Mathis" >Subject: New Version Notification for draft-ietf-conex-abstract-mech-07.txt >Date: Mon, 15 Jul 2013 15:38:37 -0700 > > >A new version of I-D, draft-ietf-conex-abstract-mech-07.txt >has been successfully submitted by Matt Mathis and posted to the >IETF repository. > >Filename: draft-ietf-conex-abstract-mech >Revision: 07 >Title: Congestion Exposure (ConEx) Concepts and Abstract Mechanism >Creation date: 2013-07-15 >Group: conex >Number of pages: 28 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-07.txt >Status: >http://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech >Htmlized: http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-07 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-abstract-mech-07 > >Abstract: > This document describes an abstract mechanism by which senders inform > the network about the congestion encountered by packets earlier in > the same flow. Today, network elements at any layer may signal > congestion to the receiver by dropping packets or by ECN markings, > and the receiver passes this information back to the sender in > transport-layer feedback. The mechanism described here enables the > sender to also relay this congestion information back into the > network in-band at the IP layer, such that the total amount of > congestion from all elements on the path is revealed to all IP > elements along the path, where it could, for example, be used to > provide input to traffic management. This mechanism is called > congestion exposure or ConEx. The companion document "ConEx Concepts > and Use Cases" provides the entry-point to the set of ConEx > documentation. > > > > > >The IETF Secretariat ________________________________________________________________ Bob Briscoe, BT From marcelo@it.uc3m.es Tue Jul 16 08:27: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 8D4D221F9B90 for ; Tue, 16 Jul 2013 08:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 5RjbEXWineVZ for ; Tue, 16 Jul 2013 08:27:07 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF4C21F9C33 for ; Tue, 16 Jul 2013 08:27:01 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5AEA1894DB9 for ; Tue, 16 Jul 2013 17:27:00 +0200 (CEST) X-uc3m-safe: yes Received: from [163.117.203.99] (unknown [163.117.203.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 23D0A76B776 for ; Tue, 16 Jul 2013 17:26:59 +0200 (CEST) Message-ID: <51E56642.6020300@it.uc3m.es> Date: Tue, 16 Jul 2013 17:26:58 +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 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Tue, 16 Jul 2013 17:27:00 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20018.007 X-TM-AS-Result: No--7.818-7.0-31-1 X-imss-scan-details: No--7.818-7.0-31-1 Subject: [conex] berlin meeting agenda 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, 16 Jul 2013 15:27:18 -0000 Hi, find it at: http://www.ietf.org/proceedings/87/agenda/agenda-87-conex Let me know if you have comments. Regards, marcelo From bob.briscoe@bt.com Tue Jul 30 13:07: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 35B1321E80C0 for ; Tue, 30 Jul 2013 13:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.121, 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 lHbPGmlug+2v for ; Tue, 30 Jul 2013 13:07:40 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id A734421E80A1 for ; Tue, 30 Jul 2013 13:07:39 -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; Tue, 30 Jul 2013 21:07:38 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 30 Jul 2013 21:07:37 +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, 30 Jul 2013 21:07:25 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.132.131]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6UK7MB5014174; Tue, 30 Jul 2013 21:07:23 +0100 Message-ID: <201307302007.r6UK7MB5014174@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Jul 2013 21:05:40 +0100 To: David Wagner , Mirja =?iso-8859-1?Q?K=FChlewind?= From: Bob Briscoe In-Reply-To: <7.1.0.9.2.20130715181301.0e00a5a8@bt.com> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306101944.38261.david.wagner@ikr.uni-stuttgart.de> <201307151132.r6FBWPsT011095@bagheera.jungle.bt.co.uk> <201307151657.02177.david.wagner@ikr.uni-stuttgart.de> <7.1.0.9.2.20130715181301.0e00a5a8@bt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Tue, 30 Jul 2013 20:07:45 -0000 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 From david.wagner@ikr.uni-stuttgart.de Tue Jul 30 17: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 2B15321E810A for ; Tue, 30 Jul 2013 17: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 Vg7mjisI8eY7 for ; Tue, 30 Jul 2013 17: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 1D81521E80AE for ; Tue, 30 Jul 2013 17: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 65F8760159; Wed, 31 Jul 2013 02:33:57 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 4273C60158; Wed, 31 Jul 2013 02:33:57 +0200 (CEST) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe Date: Wed, 31 Jul 2013 02:33:56 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <7.1.0.9.2.20130715181301.0e00a5a8@bt.com> <201307302007.r6UK7MB5014174@bagheera.jungle.bt.co.uk> In-Reply-To: <201307302007.r6UK7MB5014174@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: <201307310233.56714.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, 31 Jul 2013 00:34:04 -0000 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 ------------------------------------------------------------------- From bob.briscoe@bt.com Wed Jul 31 00:57:17 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 1CDAB11E8174 for ; Wed, 31 Jul 2013 00:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 LDTXdMwKEQVu for ; Wed, 31 Jul 2013 00:57:12 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id F010721F9FE1 for ; Wed, 31 Jul 2013 00:57:11 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 31 Jul 2013 08:57:09 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 31 Jul 2013 08:57:09 +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; Wed, 31 Jul 2013 08:57:04 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.135.64]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6V7v2lS016065; Wed, 31 Jul 2013 08:57:03 +0100 Message-ID: <201307310757.r6V7v2lS016065@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 31 Jul 2013 08:57:01 +0100 To: David Wagner From: Bob Briscoe In-Reply-To: <201307310233.56714.david.wagner@ikr.uni-stuttgart.de> References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <7.1.0.9.2.20130715181301.0e00a5a8@bt.com> <201307302007.r6UK7MB5014174@bagheera.jungle.bt.co.uk> <201307310233.56714.david.wagner@ikr.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Wed, 31 Jul 2013 07:57:17 -0000 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