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

[Mirja Kuehlewind <[e-mail]>]

Hi Bob,

another definition could be:

A credits gets invalid/is used when a new congestion signal (CE or loss) 
arrives at the audit and the number of congestion-marked or lost packets 
(red) is currently larger than ConEx-marked ones (black/purple).

This would mean you potentially have to resend credits when congestion occurs.

Mirja


On Sunday 16 June 2013 08:34:35 Bob Briscoe wrote:
> Mirja,
>
> At 16:03 09/06/2013, Mirja Kühlewind wrote:
> >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...?
>
> I would rather we supported diversity by stating
> one concrete definition, and allowed experiments
> with other definitions. But I would (naturally)
> prefer my definition (ie credit lasts for as long
> as a flow is active, and an auditor MAY time out
> a flow after no less than 1 second of inactivity).
>
> Actually, I think this is the only concrete
> definition on the table, unless you have a
> proposal for exactly how to define your idea of credit gradually expiring.
>
> > > >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
>
> That's not such a big problem, although I admit
> it devalues the distinction between Credit &
> Re-Echo, and I admit too that I don't have a solution to that.
>
> >and moreover there is
> >still no incentive to send further marks when you have build up a large
> >number of credits during Slow Start.
>
> My proposed definition of credit means that the sender wouldn't need to.
>
> It's not ideal from a network monitoring point of
> view for the network to see such an anomalous
> amount of credit and nothing to be able to
> monitor recent actual congestion. But at least it
> still provides full incentives against cheating.
>
> And, much more importantly, it also provides
> incentives to slow-start more carefully (e.g.
> watching the ACK timing to detect onset of
> overshoot a round trip earlier), so that so much
> credit isn't wasted. The Linux patch to do this
> was too gentle, but the developers gave up
> because at the time there was no way to reason
> about how much less gentle it should be - ConEx provides that.
>
> > > >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).
>
> See above.
>
> >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.
>
> Audit would only lose state due to a re-route.*
> Then, admittedly it would lose a load of credit,
> but if the sender's flow was in progress, it
> wouldn't need a huge repeat of credit again. Just
> one, or perhaps two, ConEx re-echoes in response
> to the ensuing audit losses would be sufficient to re-instate the audit
> state.
>
> * = (If audit has mem restrictions it would not
> have set the state in the first place.)
>
> > > >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.
>
> Going back on what I say below, I think it would
> be better to state one full definition of credit
> in abstr mech, just to be concrete, but then say
> that if anyone prefers another definition, they
> are encouraged to experiment with it and write up the outcome.
>
> > > [BB]: I don't think it should either. This is a
> > > discussion with Mirja, rather than a proposal for text.
>
> Tx again for you review.
>
>
> Bob
>
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------