From bob.briscoe@bt.com Thu Oct 17 01:26: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 A126411E80F5 for ; Thu, 17 Oct 2013 01:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 HMCIwxAtZWY3 for ; Thu, 17 Oct 2013 01:26:39 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D821F92E7 for ; Thu, 17 Oct 2013 01:26:33 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 17 Oct 2013 09:26:30 +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; Thu, 17 Oct 2013 09:26:15 +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.347.0; Thu, 17 Oct 2013 09:26:10 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.159.118]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9H8Q8RC002174; Thu, 17 Oct 2013 09:26:09 +0100 Message-ID: <201310170826.r9H8Q8RC002174@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Oct 2013 18:52:29 +0100 To: Marcelo BAGNULO BRAUN , Nandita Dukkipati 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 Cc: ConEx IETF list Subject: [conex] ConEx credit & audit: status update 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, 17 Oct 2013 08:26:45 -0000 ConEx chairs, David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 days to sort out whether the approach to credit the w-g agreed is correct and feasible. You may recall that last July we agreed at the working group meeting in Berlin to go with David Wagner's idea of requiring audit to check for a non-negative balance of (credit - (loss or ECN)) as well as (re-echo - (loss or ECN)), so the source has to effectively 'pay' twice for congestion, with credit and with re-echo. (See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion Surcharge") The more I think about the idea, the more I like it - I'm grateful to David for thinking up this idea - it's solved an otherwise major problem. We all agree that there are still some niggles with it, which we will write up by updating David's draft (above). But more importantly (if the relevant co-authors agree) we will reflect this change in thinking with the relevant normative text in: draft-ietf-conex-destopt and draft-ietf-conex-tcp-modifications. For these expt track docs, we aim to issue new revisions before Monday's deadline, even there is no ConEx meeting planned for Vancouver. We intend to write up a full (Informational) spec of audit and credit by revising draft-wagner-conex-credit-00 (we may use a new filename to include the word audit). This will document all the potential attacks against ConEx and the way the audit function handles them. We'll need to build a new implementation to test it, then we can include reference pseudocode in the draft (all the ideas from the auditor in my PhD that Toby Moncaster implemented are just as applicable to these attacks, even with the change in the definition of credit). Matt Mathis & I will also be making the few promised updates to conex-abstract-mech (Informational) before Monday. Bob ________________________________________________________________ Bob Briscoe, BT From david.wagner@ikr.uni-stuttgart.de Fri Oct 18 06:28:27 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B979411E81CC for ; Fri, 18 Oct 2013 06:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDuJ0Z5tOlfy for ; Fri, 18 Oct 2013 06:28:24 -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 6484111E8112 for ; Fri, 18 Oct 2013 06:28:22 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id E7D446027F; Fri, 18 Oct 2013 15:28:11 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id E11406027E; Fri, 18 Oct 2013 15:28:11 +0200 (CEST) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe , Matt Mathis Date: Fri, 18 Oct 2013 15:28:10 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310170826.r9H8Q8RC002174@bagheera.jungle.bt.co.uk> In-Reply-To: <201310170826.r9H8Q8RC002174@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: <201310181528.10870.david.wagner@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] ConEx credit & audit: status update 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, 18 Oct 2013 13:28:27 -0000 Hi *, we now are sure to understand that credit will not allow to completely avoid handling time estimations in the audit, but rather represents a risk for future congestion. Therefore, I think we should change the respective section in abstract-mech and we even could change the term to something more distinct like "congestion risk". I'd propose to keep the word credit to not cause (more) confusion but to make clear the meaning of that signal in the abstract-mech draft. I would then refer to that text in the audit draft. Agree? David On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote: > ConEx chairs, > > David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 > days to sort out whether the approach to credit the w-g agreed is > correct and feasible. > > You may recall that last July we agreed at the working group meeting > in Berlin to go with David Wagner's idea of requiring audit to check > for a non-negative balance of (credit - (loss or ECN)) as well as > (re-echo - (loss or ECN)), so the source has to effectively 'pay' > twice for congestion, with credit and with re-echo. > (See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion > Surcharge") > > The more I think about the idea, the more I like it - I'm grateful to > David for thinking up this idea - it's solved an otherwise major > problem. We all agree that there are still some niggles with it, > which we will write up by updating David's draft (above). > > But more importantly (if the relevant co-authors agree) we will > reflect this change in thinking with the relevant normative text in: > draft-ietf-conex-destopt and > draft-ietf-conex-tcp-modifications. > > For these expt track docs, we aim to issue new revisions before > Monday's deadline, even there is no ConEx meeting planned for Vancouver. > > We intend to write up a full (Informational) spec of audit and credit > by revising > draft-wagner-conex-credit-00 (we may use a new filename to > include the word audit). > > This will document all the potential attacks against ConEx and the > way the audit function handles them. We'll need to build a new > implementation to test it, then we can include reference pseudocode > in the draft (all the ideas from the auditor in my PhD that Toby > Moncaster implemented are just as applicable to these attacks, even > with the change in the definition of credit). > > Matt Mathis & I will also be making the few promised updates to > conex-abstract-mech (Informational) > before Monday. > > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > -- Dipl.-Inf. David Wagner Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart Pfaffenwaldring 47, D-70569 Stuttgart, Germany web: www.ikr.uni-stuttgart.de email: david.wagner@ikr.uni-stuttgart.de phone: +49 711 685-67965 fax: +49 711 685-57965 ------------------------------------------------------------------- From bob.briscoe@bt.com Fri Oct 18 07:57: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 4AED211E82AB for ; Fri, 18 Oct 2013 07:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.496, 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 d-VwkWvbFZjH for ; Fri, 18 Oct 2013 07:56:48 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46E11E81D1 for ; Fri, 18 Oct 2013 07:56:35 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 18 Oct 2013 15:56:34 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 18 Oct 2013 15:56:34 +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.347.0; Fri, 18 Oct 2013 15:56:33 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9IEuVW4006981; Fri, 18 Oct 2013 15:56:31 +0100 Message-ID: <201310181456.r9IEuVW4006981@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 18 Oct 2013 15:56:31 +0100 To: David Wagner From: Bob Briscoe In-Reply-To: <201310181528.10870.david.wagner@ikr.uni-stuttgart.de> References: <201310170826.r9H8Q8RC002174@bagheera.jungle.bt.co.uk> <201310181528.10870.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] ConEx credit & audit: status update 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, 18 Oct 2013 14:57:18 -0000 David, Dealing with credit wording in abstract-mech is 2nd on my todo list now. I'm pretty sure the position is that abstract-mech is abstract. It doesn't define any details, only a thought framework. ConEx consists of a number of variables that can each be re-defined a little to allow others to be re-defined a little. This new definition of credit is not cast in stone. It's an experimental approach the w-g is running with to see where it takes us. So the correct place to define the current precise meaning of ConEx concepts is in the experimental docs (destopt), not the informational overview (abstract-mech). However, I won't completely agree or disagree with you until I've re-loaded state - I need to check what Matt was willing to agree to and consider how I could reword abstract-mech to include and hint at the new meaning of credit without over-constraining. I'll be in touch with a final decision on abstract-meach wording before the end of Saturday (hopefully). Bob At 14:28 18/10/2013, David Wagner wrote: >Hi *, > >we now are sure to understand that credit will not allow to >completely avoid handling time estimations in the audit, but rather >represents a risk for future congestion. Therefore, I think we >should change the respective section in abstract-mech and we even >could change the term to something more distinct like "congestion risk". > >I'd propose to keep the word credit to not cause (more) confusion >but to make clear the meaning of that signal in the abstract-mech >draft. I would then refer to that text in the audit draft. > >Agree? > >David > >On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote: > > ConEx chairs, > > > > David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 > > days to sort out whether the approach to credit the w-g agreed is > > correct and feasible. > > > > You may recall that last July we agreed at the working group meeting > > in Berlin to go with David Wagner's idea of requiring audit to check > > for a non-negative balance of (credit - (loss or ECN)) as well as > > (re-echo - (loss or ECN)), so the source has to effectively 'pay' > > twice for congestion, with credit and with re-echo. > > (See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion > > Surcharge") > > > > The more I think about the idea, the more I like it - I'm grateful to > > David for thinking up this idea - it's solved an otherwise major > > problem. We all agree that there are still some niggles with it, > > which we will write up by updating David's draft (above). > > > > But more importantly (if the relevant co-authors agree) we will > > reflect this change in thinking with the relevant normative text in: > > draft-ietf-conex-destopt and > > draft-ietf-conex-tcp-modifications. > > > > For these expt track docs, we aim to issue new revisions before > > Monday's deadline, even there is no ConEx meeting planned for Vancouver. > > > > We intend to write up a full (Informational) spec of audit and credit > > by revising > > draft-wagner-conex-credit-00 (we may use a new filename to > > include the word audit). > > > > This will document all the potential attacks against ConEx and the > > way the audit function handles them. We'll need to build a new > > implementation to test it, then we can include reference pseudocode > > in the draft (all the ideas from the auditor in my PhD that Toby > > Moncaster implemented are just as applicable to these attacks, even > > with the change in the definition of credit). > > > > Matt Mathis & I will also be making the few promised updates to > > conex-abstract-mech (Informational) > > before Monday. > > > > > > > > Bob > > > > > > ________________________________________________________________ > > Bob Briscoe, BT > > > > _______________________________________________ > > 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 Fri Oct 18 08:09:32 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 79E4C1F0D4F for ; Fri, 18 Oct 2013 08:09:32 -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 z9HaSMTiMUMW for ; Fri, 18 Oct 2013 08:09:28 -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 5F30211E819D for ; Fri, 18 Oct 2013 08:09:28 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id B19C960280; Fri, 18 Oct 2013 17:09:27 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A93466027D; Fri, 18 Oct 2013 17:09:27 +0200 (CEST) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe Date: Fri, 18 Oct 2013 17:09:26 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310170826.r9H8Q8RC002174@bagheera.jungle.bt.co.uk> <201310181528.10870.david.wagner@ikr.uni-stuttgart.de> <201310181456.r9IEuVW4006981@bagheera.jungle.bt.co.uk> In-Reply-To: <201310181456.r9IEuVW4006981@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: <201310181709.26620.david.wagner@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] ConEx credit & audit: status update 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, 18 Oct 2013 15:09:32 -0000 Hi Bob, I agree, the abstract document should remain abstract. :-) Anyway, right now, section 5.5.1 introduces credit as a signal used to avoid RTT-estimations at the audit (amongst other thoughts in this section). And I think we reached a state, at which we can exclude that this is possible to full extend. I think you'll reflect that in your update and just intended to clarify on which basis I start with the audit doc and that I'll continue to use the term credit. Cheers, David On Friday 18 October 2013 16:56:31 Bob Briscoe wrote: > David, > > Dealing with credit wording in abstract-mech is 2nd on my todo list now. > > I'm pretty sure the position is that abstract-mech is abstract. It > doesn't define any details, only a thought framework. ConEx consists > of a number of variables that can each be re-defined a little to > allow others to be re-defined a little. > > This new definition of credit is not cast in stone. It's an > experimental approach the w-g is running with to see where it takes > us. So the correct place to define the current precise meaning of > ConEx concepts is in the experimental docs (destopt), not the > informational overview (abstract-mech). > > However, I won't completely agree or disagree with you until I've > re-loaded state - I need to check what Matt was willing to agree to > and consider how I could reword abstract-mech to include and hint at > the new meaning of credit without over-constraining. > > I'll be in touch with a final decision on abstract-meach wording > before the end of Saturday (hopefully). > > > Bob > > At 14:28 18/10/2013, David Wagner wrote: > >Hi *, > > > >we now are sure to understand that credit will not allow to > >completely avoid handling time estimations in the audit, but rather > >represents a risk for future congestion. Therefore, I think we > >should change the respective section in abstract-mech and we even > >could change the term to something more distinct like "congestion risk". > > > >I'd propose to keep the word credit to not cause (more) confusion > >but to make clear the meaning of that signal in the abstract-mech > >draft. I would then refer to that text in the audit draft. > > > >Agree? > > > >David > > > >On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote: > > > ConEx chairs, > > > > > > David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 > > > days to sort out whether the approach to credit the w-g agreed is > > > correct and feasible. > > > > > > You may recall that last July we agreed at the working group meeting > > > in Berlin to go with David Wagner's idea of requiring audit to check > > > for a non-negative balance of (credit - (loss or ECN)) as well as > > > (re-echo - (loss or ECN)), so the source has to effectively 'pay' > > > twice for congestion, with credit and with re-echo. > > > (See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion > > > Surcharge") > > > > > > The more I think about the idea, the more I like it - I'm grateful to > > > David for thinking up this idea - it's solved an otherwise major > > > problem. We all agree that there are still some niggles with it, > > > which we will write up by updating David's draft (above). > > > > > > But more importantly (if the relevant co-authors agree) we will > > > reflect this change in thinking with the relevant normative text in: > > > draft-ietf-conex-destopt and > > > draft-ietf-conex-tcp-modifications. > > > > > > For these expt track docs, we aim to issue new revisions before > > > Monday's deadline, even there is no ConEx meeting planned for Vancouver. > > > > > > We intend to write up a full (Informational) spec of audit and credit > > > by revising > > > draft-wagner-conex-credit-00 (we may use a new filename to > > > include the word audit). > > > > > > This will document all the potential attacks against ConEx and the > > > way the audit function handles them. We'll need to build a new > > > implementation to test it, then we can include reference pseudocode > > > in the draft (all the ideas from the auditor in my PhD that Toby > > > Moncaster implemented are just as applicable to these attacks, even > > > with the change in the definition of credit). > > > > > > Matt Mathis & I will also be making the few promised updates to > > > conex-abstract-mech (Informational) > > > before Monday. > > > > > > > > > > > > Bob > > > > > > > > > ________________________________________________________________ > > > Bob Briscoe, BT > > > > > > _______________________________________________ > > > 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 > > -- 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 mattmathis@google.com Fri Oct 18 08:37:51 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725A911E8232 for ; Fri, 18 Oct 2013 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf1dyxhNN+3w for ; Fri, 18 Oct 2013 08:37:49 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5749211E810F for ; Fri, 18 Oct 2013 08:37:49 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so6937288iec.27 for ; Fri, 18 Oct 2013 08:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zVVO/FEZgZBeqUhpdTKE+eK1ok2FukJN8PTXZTIfXq4=; b=CAiex5HDdS9iiHn2I2vLENOtWeO1Yi5/QY5rvvSYXzAFt/zECThSj+36I96J2O8IgQ eBMIaVeGXQkgbGUXZpGN9OrTZWfRLxTOA8g3SPRQsatkJCKEck/nJhc6QyiQKyAfUO3V xHzonLptAq/wr8QO8otH+Ejqj3Yy01I+Q5LJJbDOqvsxa5kecr/6lfnflAUklfSEW3RB +qSRs1xAEl34BwGA3gg/j8z1Q3QA6P7oOx1mBqugvJWLFGGwmuSbzPr2aZe5YG82vvjt YvfTKt4+fXTWPCNF4wUc48IZI6yWkAsPdl2uhFAp9qi1zqJJ0Dm9qLOVgGlDsOQQBzYB DdlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zVVO/FEZgZBeqUhpdTKE+eK1ok2FukJN8PTXZTIfXq4=; b=WU2m1Z4pZrK+rFk8Q3ZxCzkl2rKy+Dl6WvNtVTx2V3mU4x/M5t41rHMHgKTHhATOBB MCbsvY0ZAsGCMmUHaIZ08reVcNb4s93kHAMTMjhUodbBFdpk+pO3Xj/l72YNlgHnDtPG +ipHxS74pOtFycawtvAbk0N8bqB9mU19Axgsv8rrpCvFPKds0WWEMA6+HnweGokpVwJd IvPqGVSFw8gM9YZKL3+GPpgKYrS1rRFolSDTCyBK4FQv2jxI6sjZ0E7ZuemIYf7Y8Lbh hsx7eVW3nq0Pa7DxE/hZ2EnZKjYhoj2XMyzkQ2akXamUidihlA64u+SIZh4FqYWOT9mU 42qA== X-Gm-Message-State: ALoCoQlHRPa6yFjyF2AdZmsLnoR5awNCRYCD85kXj9XvuVxO9awchLCmq/IjCcUMarVGprW72PkoMNdI0eq7/e54kd9oWKLWqsUOoVPsjZ6X1qQhQM2AJhZHmA5UvddYzfCHIctR3Ic3NiOVUuEv7yoXSOy6vc5DKsMs6DNjV9KjbG+l7Zx2YRfVCBymuYxatmIZUopXsckU MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr3128903igg.23.1382110668573; Fri, 18 Oct 2013 08:37:48 -0700 (PDT) Received: by 10.64.243.66 with HTTP; Fri, 18 Oct 2013 08:37:48 -0700 (PDT) In-Reply-To: <201310181709.26620.david.wagner@ikr.uni-stuttgart.de> References: <201310170826.r9H8Q8RC002174@bagheera.jungle.bt.co.uk> <201310181528.10870.david.wagner@ikr.uni-stuttgart.de> <201310181456.r9IEuVW4006981@bagheera.jungle.bt.co.uk> <201310181709.26620.david.wagner@ikr.uni-stuttgart.de> Date: Fri, 18 Oct 2013 08:37:48 -0700 Message-ID: From: Matt Mathis To: David Wagner Content-Type: multipart/alternative; boundary=047d7bdc10ec71039704e905b701 Cc: ConEx IETF list Subject: Re: [conex] ConEx credit & audit: status update 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, 18 Oct 2013 15:37:51 -0000 --047d7bdc10ec71039704e905b701 Content-Type: text/plain; charset=ISO-8859-1 I missed something: What was the feedback on Abstract Mech? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Fri, Oct 18, 2013 at 8:09 AM, David Wagner < david.wagner@ikr.uni-stuttgart.de> wrote: > Hi Bob, > > I agree, the abstract document should remain abstract. :-) > Anyway, right now, section 5.5.1 introduces credit as a signal used to > avoid RTT-estimations at the audit (amongst other thoughts in this section). > And I think we reached a state, at which we can exclude that this is > possible to full extend. > I think you'll reflect that in your update and just intended to clarify on > which basis I start with the audit doc and that I'll continue to use the > term credit. > > Cheers, > David > > > On Friday 18 October 2013 16:56:31 Bob Briscoe wrote: > > David, > > > > Dealing with credit wording in abstract-mech is 2nd on my todo list now. > > > > I'm pretty sure the position is that abstract-mech is abstract. It > > doesn't define any details, only a thought framework. ConEx consists > > of a number of variables that can each be re-defined a little to > > allow others to be re-defined a little. > > > > This new definition of credit is not cast in stone. It's an > > experimental approach the w-g is running with to see where it takes > > us. So the correct place to define the current precise meaning of > > ConEx concepts is in the experimental docs (destopt), not the > > informational overview (abstract-mech). > > > > However, I won't completely agree or disagree with you until I've > > re-loaded state - I need to check what Matt was willing to agree to > > and consider how I could reword abstract-mech to include and hint at > > the new meaning of credit without over-constraining. > > > > I'll be in touch with a final decision on abstract-meach wording > > before the end of Saturday (hopefully). > > > > > > Bob > > > > At 14:28 18/10/2013, David Wagner wrote: > > >Hi *, > > > > > >we now are sure to understand that credit will not allow to > > >completely avoid handling time estimations in the audit, but rather > > >represents a risk for future congestion. Therefore, I think we > > >should change the respective section in abstract-mech and we even > > >could change the term to something more distinct like "congestion risk". > > > > > >I'd propose to keep the word credit to not cause (more) confusion > > >but to make clear the meaning of that signal in the abstract-mech > > >draft. I would then refer to that text in the audit draft. > > > > > >Agree? > > > > > >David > > > > > >On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote: > > > > ConEx chairs, > > > > > > > > David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 > > > > days to sort out whether the approach to credit the w-g agreed is > > > > correct and feasible. > > > > > > > > You may recall that last July we agreed at the working group meeting > > > > in Berlin to go with David Wagner's idea of requiring audit to check > > > > for a non-negative balance of (credit - (loss or ECN)) as well as > > > > (re-echo - (loss or ECN)), so the source has to effectively 'pay' > > > > twice for congestion, with credit and with re-echo. > > > > (See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion > > > > Surcharge") > > > > > > > > The more I think about the idea, the more I like it - I'm grateful to > > > > David for thinking up this idea - it's solved an otherwise major > > > > problem. We all agree that there are still some niggles with it, > > > > which we will write up by updating David's draft (above). > > > > > > > > But more importantly (if the relevant co-authors agree) we will > > > > reflect this change in thinking with the relevant normative text in: > > > > draft-ietf-conex-destopt and > > > > draft-ietf-conex-tcp-modifications. > > > > > > > > For these expt track docs, we aim to issue new revisions before > > > > Monday's deadline, even there is no ConEx meeting planned for > Vancouver. > > > > > > > > We intend to write up a full (Informational) spec of audit and credit > > > > by revising > > > > draft-wagner-conex-credit-00 (we may use a new filename to > > > > include the word audit). > > > > > > > > This will document all the potential attacks against ConEx and the > > > > way the audit function handles them. We'll need to build a new > > > > implementation to test it, then we can include reference pseudocode > > > > in the draft (all the ideas from the auditor in my PhD that Toby > > > > Moncaster implemented are just as applicable to these attacks, even > > > > with the change in the definition of credit). > > > > > > > > Matt Mathis & I will also be making the few promised updates to > > > > conex-abstract-mech (Informational) > > > > before Monday. > > > > > > > > > > > > > > > > Bob > > > > > > > > > > > > ________________________________________________________________ > > > > Bob Briscoe, BT > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > -- > 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 > ------------------------------------------------------------------- > --047d7bdc10ec71039704e905b701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I missed something: What was the feedback on Abstract Mech= ?

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

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


On Fri, Oct 18, 2013 at 8:09 AM, David W= agner <david.wagner@ikr.uni-stuttgart.de> wr= ote:
Hi Bob,

I agree, the abstract document should remain abstract. :-)
Anyway, right now, section 5.5.1 introduces credit as a signal used to avoi= d RTT-estimations at the audit (amongst other thoughts in this section). And I think we reached a state, at which we can exclude that this is possib= le to full extend.
I think you'll reflect that in your update and just intended to clarify= on which basis I start with the audit doc and that I'll continue to us= e the term credit.

Cheers,
David


On Friday 18 October 2013 16:56:31 Bob Briscoe wrote:
> David,
>
> Dealing with credit wording in abstract-mech is 2nd on my todo list no= w.
>
> I'm pretty sure the position is that abstract-mech is abstract. It=
> doesn't define any details, only a thought framework. ConEx consis= ts
> of a number of variables that can each be re-defined a little to
> allow others to be re-defined a little.
>
> This new definition of credit is not cast in stone. It's an
> experimental approach the w-g is running with to see where it takes > us. So the correct place to define the current precise meaning of
> ConEx concepts is in the experimental docs (destopt), not the
> informational overview (abstract-mech).
>
> However, I won't completely agree or disagree with you until I'= ;ve
> re-loaded state - I need to check what Matt was willing to agree to > and consider how I could reword abstract-mech to include and hint at > the new meaning of credit without over-constraining.
>
> I'll be in touch with a final decision on abstract-meach wording > before the end of Saturday (hopefully).
>
>
> Bob
>
> At 14:28 18/10/2013, David Wagner wrote:
> >Hi *,
> >
> >we now are sure to understand that credit will not allow to
> >completely avoid handling time estimations in the audit, but rathe= r
> >represents a risk for future congestion. Therefore, I think we
> >should change the respective section in abstract-mech and we even<= br> > >could change the term to something more distinct like "conges= tion risk".
> >
> >I'd propose to keep the word credit to not cause (more) confus= ion
> >but to make clear the meaning of that signal in the abstract-mech<= br> > >draft. I would then refer to that text in the audit draft.
> >
> >Agree?
> >
> >David
> >
> >On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote:
> > > ConEx chairs,
> > >
> > > David Wagner, Mirja Kuehlewind & I have been meeting ove= r the past 2
> > > days to sort out whether the approach to credit the w-g agre= ed is
> > > correct and feasible.
> > >
> > > You may recall that last July we agreed at the working group= meeting
> > > in Berlin to go with David Wagner's idea of requiring au= dit to check
> > > for a non-negative balance of (credit - (loss or ECN)) as we= ll as
> > > (re-echo - (loss or ECN)), so the source has to effectively = 'pay'
> > > twice for congestion, with credit and with re-echo.
> > > (See draft-wagner-conex-credit-00 Section.3.3. "Credit = As Congestion
> > > Surcharge")
> > >
> > > The more I think about the idea, the more I like it - I'= m grateful to
> > > David for thinking up this idea - it's solved an otherwi= se major
> > > problem. We all agree that there are still some niggles with= it,
> > > which we will write up by updating David's draft (above)= .
> > >
> > > But more importantly (if the relevant co-authors agree) we w= ill
> > > reflect this change in thinking with the relevant normative = text in:
> > > =A0 =A0 =A0 =A0 =A0draft-ietf-conex-destopt and
> > > =A0 =A0 =A0 =A0 =A0draft-ietf-conex-tcp-modifications.
> > >
> > > For these expt track docs, we aim to issue new revisions bef= ore
> > > Monday's deadline, even there is no ConEx meeting planne= d for Vancouver.
> > >
> > > We intend to write up a full (Informational) spec of audit a= nd credit
> > > by revising
> > > =A0 =A0 =A0 =A0 =A0draft-wagner-conex-credit-00 (we may use = a new filename to
> > > include the word audit).
> > >
> > > This will document all the potential attacks against ConEx a= nd the
> > > way the audit function handles them. We'll need to build= a new
> > > implementation to test it, then we can include reference pse= udocode
> > > in the draft (all the ideas from the auditor in my PhD that = Toby
> > > Moncaster implemented are just as applicable to these attack= s, even
> > > with the change in the definition of credit).
> > >
> > > Matt Mathis & I will also be making the few promised upd= ates to
> > > =A0 =A0 =A0 =A0 =A0conex-abstract-mech (Informational)
> > > before Monday.
> > >
> > >
> > >
> > > Bob
> > >
> > >
> > > ____________________________________________________________= ____
> > > Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BT
> > >
> > > _______________________________________________
> > > 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 =A0 email: david.wagner@ikr.uni-stuttgart.de
> >phone: +49 711 685-67965 =A0 =A0 =A0 =A0fax: +49 711 685-57965
> >------------------------------------------------------------------= -
>
> ________________________________________________________________
> Bob Briscoe, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BT
>
>


--
Dipl.-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 =A0 email: david.wagner@ikr.uni-stuttgart.de
phone: +49= 711 685-67965 =A0 =A0 =A0 =A0fax: +49 711 685-57965
-------------------------------------------------------------------

--047d7bdc10ec71039704e905b701-- From david.wagner@ikr.uni-stuttgart.de Fri Oct 18 09:12: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 0C98111E827A for ; Fri, 18 Oct 2013 09:12: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 XJ6l93V9rmBF for ; Fri, 18 Oct 2013 09:12: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 EED1C11E81CB for ; Fri, 18 Oct 2013 09:12:08 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 2902460280; Fri, 18 Oct 2013 18:12:08 +0200 (CEST) Received: from vpn-2-cl181 (vpn-2-cl181 [10.41.21.181]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 173FA6027D; Fri, 18 Oct 2013 18:12:08 +0200 (CEST) From: David Wagner Organization: University of Stuttgart (Germany), IKR To: Matt Mathis Date: Fri, 18 Oct 2013 18:12:06 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310170826.r9H8Q8RC002174@bagheera.jungle.bt.co.uk> <201310181709.26620.david.wagner@ikr.uni-stuttgart.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201310181812.06898.david.wagner@ikr.uni-stuttgart.de> Cc: ConEx IETF list Subject: Re: [conex] ConEx credit & audit: status update 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, 18 Oct 2013 16:12:13 -0000 Hi Matt, it only regards the text on credit. Right now, sec 5.5.1. says "However, the audit function cannot be expected to wait for a round trip to check that one signal balances the other, because that requires excessive state and the auditor cannot easily determine the RTT of each flow. ... The transport signals sufficient credit in advance to cover congestion expected during its feedback delay. Then, the audit function does not need to make allowance for round trip delays that it cannot quantify. " We found that credit does not help us from comparing current ConEx signals with ealier observed congestion signals (loss/ECE) at (now - RTT_max), maybe see my Berlin slides, slide 10. http://www.ietf.org/proceedings/87/slides/slides-87-conex-2.pdf But we deem there is still a benefit in having a separate signal for yet-to-come congestion or congestion risk, e.g. allowing to police on the aggressiveness of slow starting flows. Therefore, I think this section needs a revision, concerning the motivation for the credit signal. David On Friday 18 October 2013 17:37:48 Matt Mathis wrote: > I missed something: What was the feedback on Abstract Mech? > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy and > security as matters of life and death, because for some users, they are. > > > On Fri, Oct 18, 2013 at 8:09 AM, David Wagner < > david.wagner@ikr.uni-stuttgart.de> wrote: > > > Hi Bob, > > > > I agree, the abstract document should remain abstract. :-) > > Anyway, right now, section 5.5.1 introduces credit as a signal used to > > avoid RTT-estimations at the audit (amongst other thoughts in this section). > > And I think we reached a state, at which we can exclude that this is > > possible to full extend. > > I think you'll reflect that in your update and just intended to clarify on > > which basis I start with the audit doc and that I'll continue to use the > > term credit. > > > > Cheers, > > David > > > > > > On Friday 18 October 2013 16:56:31 Bob Briscoe wrote: > > > David, > > > > > > Dealing with credit wording in abstract-mech is 2nd on my todo list now. > > > > > > I'm pretty sure the position is that abstract-mech is abstract. It > > > doesn't define any details, only a thought framework. ConEx consists > > > of a number of variables that can each be re-defined a little to > > > allow others to be re-defined a little. > > > > > > This new definition of credit is not cast in stone. It's an > > > experimental approach the w-g is running with to see where it takes > > > us. So the correct place to define the current precise meaning of > > > ConEx concepts is in the experimental docs (destopt), not the > > > informational overview (abstract-mech). > > > > > > However, I won't completely agree or disagree with you until I've > > > re-loaded state - I need to check what Matt was willing to agree to > > > and consider how I could reword abstract-mech to include and hint at > > > the new meaning of credit without over-constraining. > > > > > > I'll be in touch with a final decision on abstract-meach wording > > > before the end of Saturday (hopefully). > > > > > > > > > Bob > > > > > > At 14:28 18/10/2013, David Wagner wrote: > > > >Hi *, > > > > > > > >we now are sure to understand that credit will not allow to > > > >completely avoid handling time estimations in the audit, but rather > > > >represents a risk for future congestion. Therefore, I think we > > > >should change the respective section in abstract-mech and we even > > > >could change the term to something more distinct like "congestion risk". > > > > > > > >I'd propose to keep the word credit to not cause (more) confusion > > > >but to make clear the meaning of that signal in the abstract-mech > > > >draft. I would then refer to that text in the audit draft. > > > > > > > >Agree? > > > > > > > >David > > > > > > > >On Wednesday 16 October 2013 19:52:29 Bob Briscoe wrote: > > > > > ConEx chairs, > > > > > > > > > > David Wagner, Mirja Kuehlewind & I have been meeting over the past 2 > > > > > days to sort out whether the approach to credit the w-g agreed is > > > > > correct and feasible. > > > > > > > > > > You may recall that last July we agreed at the working group meeting > > > > > in Berlin to go with David Wagner's idea of requiring audit to check > > > > > for a non-negative balance of (credit - (loss or ECN)) as well as > > > > > (re-echo - (loss or ECN)), so the source has to effectively 'pay' > > > > > twice for congestion, with credit and with re-echo. > > > > > (See draft-wagner-conex-credit-00 Section.3.3. "Credit As Congestion > > > > > Surcharge") > > > > > > > > > > The more I think about the idea, the more I like it - I'm grateful to > > > > > David for thinking up this idea - it's solved an otherwise major > > > > > problem. We all agree that there are still some niggles with it, > > > > > which we will write up by updating David's draft (above). > > > > > > > > > > But more importantly (if the relevant co-authors agree) we will > > > > > reflect this change in thinking with the relevant normative text in: > > > > > draft-ietf-conex-destopt and > > > > > draft-ietf-conex-tcp-modifications. > > > > > > > > > > For these expt track docs, we aim to issue new revisions before > > > > > Monday's deadline, even there is no ConEx meeting planned for > > Vancouver. > > > > > > > > > > We intend to write up a full (Informational) spec of audit and credit > > > > > by revising > > > > > draft-wagner-conex-credit-00 (we may use a new filename to > > > > > include the word audit). > > > > > > > > > > This will document all the potential attacks against ConEx and the > > > > > way the audit function handles them. We'll need to build a new > > > > > implementation to test it, then we can include reference pseudocode > > > > > in the draft (all the ideas from the auditor in my PhD that Toby > > > > > Moncaster implemented are just as applicable to these attacks, even > > > > > with the change in the definition of credit). > > > > > > > > > > Matt Mathis & I will also be making the few promised updates to > > > > > conex-abstract-mech (Informational) > > > > > before Monday. > > > > > > > > > > > > > > > > > > > > Bob > > > > > > > > > > > > > > > ________________________________________________________________ > > > > > Bob Briscoe, BT > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > -- > > 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 > > ------------------------------------------------------------------- > > > -- 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 mirja.kuehlewind@ikr.uni-stuttgart.de Mon Oct 21 10:29:11 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39311E86C1 for ; Mon, 21 Oct 2013 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.184, 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 wLQuUiAOyPTH for ; Mon, 21 Oct 2013 10:29: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 0E02611E86BD for ; Mon, 21 Oct 2013 10:29:07 -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 CC698602EE; Mon, 21 Oct 2013 19:29:05 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C5D5760038; Mon, 21 Oct 2013 19:29:05 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: Bob Briscoe Date: Mon, 21 Oct 2013 19:29:05 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <201310191353.14159.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310191602.r9JG2NjW010985@bagheera.jungle.bt.co.uk> In-Reply-To: <201310191602.r9JG2NjW010985@bagheera.jungle.bt.co.uk> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201310211929.05331.mirja.kuehlewind@ikr.uni-stuttgart.de> Cc: conex@ietf.org Subject: Re: [conex] ConEx Dest Opt 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, 21 Oct 2013 17:29:11 -0000 Hi Bob, I cc'ed the list. Thanks for you reply, see comments below. On Saturday 19 October 2013 18:02:22 Bob Briscoe wrote: > Mirja, > > Cc any reply to the list if you want. > > At 12:53 19/10/2013, Mirja K=FChlewind wrote: > >Hi, > > > >I'm currently working on the CDO draft. If have two questions where I'm > > not sure about the right answer at the moment (independent of crediting > > actually). Maybe someone of you already has an answer: > > > >1) Should ConEx marked packets preferentially not be dropped? This could > > help the audit but it would overestimate the congestion level. > > -> I would say no, because chances that marked packets get drop are > > anyway lower (?) because marks are usually sent after a window reductio= n. > > And this could potentially be exploited negatively...? > > You're thinking only in terms of what a compliant > TCP will do, not what an attacker might do... > > Optionally, preferential drop should discard with > the following drop pref (1 means drop first): > Not-ConEx or no destopt: 1 > X (but not L,E or C): 2 > X and L,E or C: 3 > > Otherwise a DDoS source can just not re-echo > ConEx and flood the queues before the first audit > function without being limited by an ingress policer. > > There is no known way to game this - Mark > Handley, me and others thought through this when > we were first considering re-ECN as a mitigation of DDoS. > > See > > for useful wording on preferential discard (but with re-ECN codepoints). > > However, this has to be OPTIONAL because it's not > so neat to expect a queue to drop based on a > destopt, which is meant to be e2e. We should ask > on the list whether this is likely to be > controversial with the IESG. I think OPTIONAL should be OK. Okay, agree, but should this be described/discussed in the ConEx Dest Opt=20 document? > > >2) ConEx marks should be immutable. What to do or how to detect if someo= ne > >changed the marking on the path. > > You can borrow the words from the last para of > the re-ECN Security Considerations if you want: > > > This would require some future modification to > the L4 transport, so the receiver can feed back > ConEx markings to the sender (re-re-feedback) - > only random ones - don't need it all the time. We > don't have to do this now, just allow for it in future. Not sure, if I even want to mention this option in the CDO draft (or anywhe= re=20 else)...? > > Alternatively, an IPsec authentication header > could be used, because the destopt would > automatically be covered by e2e IPSec AH. > However, the text says it's better not to reveal > to the network whether the endpoints are > protecting against changes to ConEx fields. > Otherwise a network will just attack packets that > aren't protected. it is preferable for random > checks to tend to protect everyone, rather than > just protecting those doing the checks. Not sure I get your point here. If you want to be protected, use IPSec AH, = no?=20 I don't see a problem here. > > >Furthermore, should invalid bit combinations > >be ignored or should the packet get dropped or something else...? > > -> Don't know... > > I think the only invalid bit combination is not-X with L,E or C. > > This could be solved by just not having the X > flag. The existence of the destopt could imply > ConEx-capable. However, that would make header overhead variable within a > flow. > > Easiest to say L,E or C implies ConEx-capable, even if X is off. > Then you have to say the packet should be > forwarded unchanged and the inconsistency > ignored. This would allow some future meaning to > be assigned to L,E or C with X off. Currently the drafts says if X is off, L, E and C are undefined. Yes, that= =20 allows for future usage but would imply to ignore L, E or C if X is off. Th= is=20 contradicts your first sentence which is saying that L, E or C implies=20 ConEx-capable. I believe I tent to leave it as it is, saying that E, L, and C should be=20 ignored if X is off and additionally saying explicit that no action (drop)= =20 should be take if this case occurs. Okay? Mirja > > > Bob > > >Any ideas? > > > >Mirja > > ________________________________________________________________ > Bob Briscoe, BT =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From bob.briscoe@bt.com Mon Oct 21 11:41: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 C7EAE11E8222 for ; Mon, 21 Oct 2013 11:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 3LIhabJVz2Jz for ; Mon, 21 Oct 2013 11:41:02 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9B11E8235 for ; Mon, 21 Oct 2013 11:40:54 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 21 Oct 2013 19:40:53 +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, 21 Oct 2013 19:40:52 +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.347.0; Mon, 21 Oct 2013 19:40:51 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.172.154]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9LIeot7024405; Mon, 21 Oct 2013 19:40:50 +0100 Message-ID: <201310211840.r9LIeot7024405@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Oct 2013 19:40:49 +0100 To: Mirja Kuehlewind From: Bob Briscoe In-Reply-To: <201310211929.05331.mirja.kuehlewind@ikr.uni-stuttgart.de> References: <201310191353.14159.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310191602.r9JG2NjW010985@bagheera.jungle.bt.co.uk> <201310211929.05331.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.org Subject: Re: [conex] ConEx Dest Opt 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, 21 Oct 2013 18:41:07 -0000 Mirja, At 18:29 21/10/2013, Mirja Kuehlewind wrote: >Hi Bob, > >I cc'ed the list. > >Thanks for you reply, see comments below. > >On Saturday 19 October 2013 18:02:22 Bob Briscoe wrote: > > Mirja, > > > > Cc any reply to the list if you want. > > > > At 12:53 19/10/2013, Mirja K=FChlewind wrote: > > >Hi, > > > > > >I'm currently working on the CDO draft. If have two questions where I'm > > > not sure about the right answer at the moment (independent of= crediting > > > actually). Maybe someone of you already has an answer: > > > > > >1) Should ConEx marked packets preferentially not be dropped? This= could > > > help the audit but it would overestimate the congestion level. > > > -> I would say no, because chances that marked packets get drop are > > > anyway lower (?) because marks are usually sent after a window= reduction. > > > And this could potentially be exploited negatively...? > > > > You're thinking only in terms of what a compliant > > TCP will do, not what an attacker might do... > > > > Optionally, preferential drop should discard with > > the following drop pref (1 means drop first): > > Not-ConEx or no destopt: 1 > > X (but not L,E or C): 2 > > X and L,E or C: 3 > > > > Otherwise a DDoS source can just not re-echo > > ConEx and flood the queues before the first audit > > function without being limited by an ingress policer. > > > > There is no known way to game this - Mark > > Handley, me and others thought through this when > > we were first considering re-ECN as a mitigation of DDoS. > > > > See > >= > > for useful wording on preferential discard (but with re-ECN codepoints). > > > > However, this has to be OPTIONAL because it's not > > so neat to expect a queue to drop based on a > > destopt, which is meant to be e2e. We should ask > > on the list whether this is likely to be > > controversial with the IESG. I think OPTIONAL should be OK. >Okay, agree, but should this be described/discussed in the ConEx Dest Opt >document? It's the only place it can be discussed. So yes. It's experimental, so the IESG should be able to allow it through. > > > > >2) ConEx marks should be immutable. What to do or how to detect if= someone > > >changed the marking on the path. > > > > You can borrow the words from the last para of > > the re-ECN Security Considerations if you want: > >= > > > > This would require some future modification to > > the L4 transport, so the receiver can feed back > > ConEx markings to the sender (re-re-feedback) - > > only random ones - don't need it all the time. We > > don't have to do this now, just allow for it in future. >Not sure, if I even want to mention this option in the CDO draft (or= anywhere >else)...? The requirement is already stated in=20 abstract-mech, so no need to say it elsewhere yet. If it were put anywhere, it would be in a ConEx transport spec. But there's no need to mention this even in conex-tcp-mods at this stage. It's definitely not relevant to conex-dest-opt.=20 All you have to say there is that the field is immutable. > > > > Alternatively, an IPsec authentication header > > could be used, because the destopt would > > automatically be covered by e2e IPSec AH. > > However, the text says it's better not to reveal > > to the network whether the endpoints are > > protecting against changes to ConEx fields. > > Otherwise a network will just attack packets that > > aren't protected. it is preferable for random > > checks to tend to protect everyone, rather than > > just protecting those doing the checks. >Not sure I get your point here. If you want to=20 >be protected, use IPSec AH, no? >I don't see a problem here. Don't worry - it's not important. It's a subtle=20 point that there are two ways to protect yourself: - an obvious and visible way (AH) - a randomised stealth way that also has the nice=20 effect that the network cannot see who is=20 protected, so it doesn't risk its reputation and=20 avoids attacks anyone, in case it attacks someone who can detect the attack. Bob > > > > >Furthermore, should invalid bit combinations > > >be ignored or should the packet get dropped or something else...? > > > -> Don't know... > > > > I think the only invalid bit combination is not-X with L,E or C. > > > > This could be solved by just not having the X > > flag. The existence of the destopt could imply > > ConEx-capable. However, that would make header overhead variable within= a > > flow. > > > > Easiest to say L,E or C implies ConEx-capable, even if X is off. > > Then you have to say the packet should be > > forwarded unchanged and the inconsistency > > ignored. This would allow some future meaning to > > be assigned to L,E or C with X off. >Currently the drafts says if X is off, L, E and C are undefined. Yes, that >allows for future usage but would imply to ignore L, E or C if X is off.= This >contradicts your first sentence which is saying that L, E or C implies >ConEx-capable. > >I believe I tent to leave it as it is, saying that E, L, and C should be >ignored if X is off and additionally saying explicit that no action (drop) >should be take if this case occurs. Okay? > >Mirja > > > > > > > Bob > > > > >Any ideas? > > > > > >Mirja > > > > ________________________________________________________________ > > 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 internet-drafts@ietf.org Mon Oct 21 15:36:09 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 0A2C721E8090; Mon, 21 Oct 2013 15:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 EgDePAXcU4Ji; Mon, 21 Oct 2013 15:36:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BEE11E874C; Mon, 21 Oct 2013 15:35:50 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021223550.32508.99391.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:35:50 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-abstract-mech-08.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:36:09 -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-08.txt Pages : 29 Date : 2013-10-21 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-abstract-mech-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 15:51:05 2013 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9451B11E86FB; Mon, 21 Oct 2013 15:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, 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 zRHKhJVGMn4R; Mon, 21 Oct 2013 15:51:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17611E87D0; Mon, 21 Oct 2013 15:50:04 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021225004.32561.36205.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:50:04 -0700 Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:51:06 -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 : IPv6 Destination Option for ConEx Author(s) : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-05.txt Pages : 8 Date : 2013-10-21 Abstract: ConEx is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-conex-destopt-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-conex-destopt-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/