> -----Original Message----- > From: Alissa Cooper [mailto:[email protected]] > Sent: Monday, December 14, 2015 1:49 AM > To: Cullen Jennings > Cc: Songhaibin (A); p2psip; [email protected] > Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 - crazy > send math .... > > > > On Dec 8, 2015, at 8:10 AM, Cullen Jennings (fluffy) <[email protected]> > wrote: > > > > > >> 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. > > Thanks Cullen. > > I think the draft needs some text to explain the above. Haibin, do you think > you > could draft something up? >
Yes. That's also my understanding of the text. I can write some text down. BR, -Haibin > 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 > > > > > > > > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
