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

[David Wagner <[e-mail]>]

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]
-------------------------------------------------------------------