Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 - crazy send math ....

[Alissa Cooper <[e-mail]>]

> On Dec 8, 2015, at 8:10 AM, Cullen Jennings (fluffy) <[e-mail]> wrote:
> 
> 
>> On Nov 11, 2015, at 4:09 PM, Alissa Cooper <[e-mail]> wrote:
>> 
>>> 
>>> The definitions of EWMA_BYTES_SENT and EWMA_BYTES_RCVD seem problematic.
>>> 
>>> sent = alpha x sent_present + (1 - alpha) x sent
>>> rcvd = alpha x rcvd_present + (1 - alpha) x rcvd
>>> 
>>> As written these equations are not right because sent/rcvd appear on both sides. It would be clearer to use last_sent and last_rcvd or some such on the right-hand side of these equations. But this begs some bigger questions:
>>> 
>>> - Does this place a requirement on all nodes implementing this specification to have to calculate these values every 5 seconds?
>>> - How are the values calculated the first time?
>>> - How was the value of 5 seconds chosen?
>>> 
>>> [Haibin] This is incorporated from the early RELOAD document. Maybe some author of the RELOAD protocol can give a better explanation.
>> 
>> This still has not been explained.
>> 
> 
> I'm sure I know what this was meant to represent when it was written .... 
> 
> sent for time period t should be set to the value of alpha times the amount sent in this time period plus (1-alpha) times the value of send for the previous time period.
> 
> The value sent for the very first time period should simply be the amount that was sent in that time period. That is not computable before the end of the time period. I doubt anyone cares what the values before the end of the first time period. Note that alpha is a constant that is probably compiled into the application and not something we expect end users to set. 

Thanks Cullen.

I think the draft needs some text to explain the above. Haibin, do you think you could draft something up?

Alissa

> 
> Basically this is a somewhat crappy infinite impulse response (IIR) filter approximation of finite impulse response (FIR) filter for computing the weighted moving average of the data transmission rate. 
> 
> Dito for rcvd.
> 
> Hope that helps, 
> 
> Cullen
> 
> 
> As an irrelevant side note  .. In practice, I have found that just reporting the raw totals number of bytes sent since the box booted then letting the management system filter and smooth that values works out better than using this
> 
> 
> 
> 
>