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

[Bob Briscoe <[e-mail]>]

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