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

Bob Briscoe <bob.briscoe@bt.com> Wed, 31 July 2013 07: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 1CDAB11E8174 for <conex@ietfa.amsl.com>; 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 <conex@ietfa.amsl.com>; 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 <conex@ietf.org>; 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 <david.wagner@ikr.uni-stuttgart.de>
From: Bob Briscoe <bob.briscoe@bt.com>
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 <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: 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
> > ><http://www.bobbriscoe.net/projects/refb/#refb-dis>
> > >
> > >>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