Re: [conex] ConEx credit & audit: status update

Bob Briscoe <bob.briscoe@bt.com> Fri, 18 October 2013 14:57 UTC

Return-Path: <bob.briscoe@bt.com>
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 <conex@ietfa.amsl.com>; 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 <conex@ietfa.amsl.com>; 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 <conex@ietf.org>; 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 <david.wagner@ikr.uni-stuttgart.de>
From: Bob Briscoe <bob.briscoe@bt.com>
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 <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=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