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

[Bob Briscoe <[e-mail]>]

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