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

[Bob Briscoe <[e-mail]>]

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
> > >> > > > [e-mail]
> > >> > > > 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: 
> [e-mail]
> > >> > >phone: [phone]        fax: [phone]
> > >> > >-------------------------------------------------------------------
> > >> >
> > >> > ________________________________________________________________
> > >> > 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: [e-mail]
>phone: [phone]        fax: [phone]
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                                  BT