Re: [conex] Crediting [was: Re: Review of draft-ietf-conex-abstract-mech-06]

Bob Briscoe <bob.briscoe@bt.com> Mon, 15 July 2013 11:32 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 C951B11E80D7 for <conex@ietfa.amsl.com>; 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 <conex@ietfa.amsl.com>; 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 <conex@ietf.org>; 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 <david.wagner@ikr.uni-stuttgart.de>
From: Bob Briscoe <bob.briscoe@bt.com>
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 <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: 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