Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

[Bob Briscoe <[e-mail]>]

Ingemar,

At 09:46 13/12/2012, Ingemar Johansson S wrote:
> > We should make it clear that the only state that re-creates 
> itself is the flow-
> > ID state, not the credit associated with it. I wrote that 
> sentence (not Matt),
> > and my motivation was to explain that a switch to a different 
> audit wouldn't
> > be catastrophic for the flow. I wasn't trying to claim that it 
> would hand-over
> > without a glitch. The audit would drop some packets, so the flow would send
> > some Re-Echo-Loss, which would establish some credit and the flow could
> > continue.
>[IJ] Hmm, perhaps I did not get that part, what you say is that if 
>the audit drops a packet, that will count as a credit ?.  This 
>credit thing is is still a mystery so I probably need to get this 
>explained better...

OK, I think I promised Marcelo I would write a draft about audit, 
with a couple of example algorithms. I suspect that would help clear 
up many of these questions.

For now, example stateful and stateless audit pseudocode and 
evaluations are here:
<http://www.bobbriscoe.net/pubs.html#refb-dis> (Section 7.6)

Here's an overview:

Very brief (for those who mostly get it already):
----------
The audit function doesn't count its own losses when balancing 
Re-Echo-Loss against Loss, because they are /audit/ losses, not 
congestion losses.

So, if a flow is re-routed to a new audit function that doesn't hold 
any state about this flow, it will start discarding  a low level of 
packets (audit discard). This will trigger the sender to Re-Echo-Loss 
in the next round trip, which will make the flow's audit balance 
positive and stop further audit discards.

So, the flow has naturally created new state at the new audit 
function without the flow explicitly knowing that the burst of loss 
was due to a re-route into a new audit function which caused the 
flow's credit state at the original audit function to be lost.


Brief but fuller explanation:
----------------------------
Re-Echo is always at least a round trip behind (longer for e.g. 
RTCP). The audit function makes the sender responsible for making the 
allowance for its feedback delay, by having to mark sufficient credit 
packets. Then the audit function can just test instantaneous 
negativity, without having to allow for RTT or feedback delays that 
it doesn't know.

I'll assume a stateful audit function (stateless is possible, but it 
has to be less precise). For the duration of a flow, a stateful audit 
function counts bytes of different ConEx markings, and it will start 
dropping packets if
* the balance of (Credit + Re-Echo-ECN  - ECN)  goes negative, or
* the balance of (Credit + Re-Echo-Loss - Loss) goes negative. {See note}

Consider a re-route where a flow is switched to a different stateful 
audit function, and assume the audit functions don't hand-over their state.

* As soon as the flow suffers any loss or ECN in the network, the 
flow will go negative at the new audit function for at least a RTT, 
because it has no credit and no Re-Echo for at least a round trip.
* So audit starts dropping packets (a very small but growing proportion).
* Importantly, the audit doesn't count these discards as loss because 
they are its own /audit/ losses not congestion losses.
* The sender gets the loss feedback from the receiver and sends some 
Re-Echo-Loss markings to balance.
* These make the flow positive at the new audit function, because it 
didn't count its own discards.

So, the flow has naturally created new state at the new audit 
function without explicitly knowing that the burst of loss was due to 
a re-route.


Cheers


Bob

{Note: Let's set aside the question of how an audit function knows 
how much loss an upstream node has done - abstract-mech talks about 
that separately.}


________________________________________________________________
Bob Briscoe,                                BT Innovate & Design