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

Bob Briscoe <bob.briscoe@bt.com> Mon, 15 July 2013 17:24 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 D9C4D11E8105 for <conex@ietfa.amsl.com>; Mon, 15 Jul 2013 10:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.506
X-Spam-Level:
X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJx7XFOBNLKh for <conex@ietfa.amsl.com>; Mon, 15 Jul 2013 10:23:57 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF2011E80AD for <conex@ietf.org>; Mon, 15 Jul 2013 10:23:51 -0700 (PDT)
Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 18:23:48 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 15 Jul 2013 18:23:49 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.342.3; Mon, 15 Jul 2013 18:23:44 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.111.124.45]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r6FHNgxb012046; Mon, 15 Jul 2013 18:23:43 +0100
Message-ID: <201307151723.r6FHNgxb012046@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 15 Jul 2013 18:23:39 +0100
To: David Wagner <david.wagner@ikr.uni-stuttgart.de>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <201307151657.02177.david.wagner@ikr.uni-stuttgart.de>
References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <201306101944.38261.david.wagner@ikr.uni-stuttgart.de> <201307151132.r6FBWPsT011095@bagheera.jungle.bt.co.uk> <201307151657.02177.david.wagner@ikr.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: conex@ietf.org
Subject: Re: [conex] Crediting [was: Re: Review of draft-ietf-conex-abstract-mech-06]
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <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 17:24:02 -0000

David,

At 15:57 15/07/2013, David Wagner wrote:
>Hi Bob,
>
>On Monday 15 July 2013 13:32:25 Bob Briscoe wrote:
> > David,
> >
> > At 18:44 10/06/2013, David Wagner wrote:
> > >Anyway, I don't yet have a good credit concept.
> >
> > Yes, this is a problem.
>I think this is a fundamental one since it questions the credibility 
>of ConEx info and thus the incentive to deploy it.

Yes, in as much as every part of a security system is fundamental, 
just as every one of the four walls around a castle is fundamental.

> > >Which also needs to address handling loss of ConEx-marked packets,
> > >at the sender and at the audit.
> >
> > I don't think of that as a problem. I may not have covered it at the
> > IETF, but I think I did in my PhD thesis.
>oops, I didn't check that.

S.7.4.4 & 7.4.5
<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