> On Nov 11, 2015, at 4:09 PM, Alissa Cooper <[email protected]> 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. 

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





_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to