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

["Songhaibin (A)" <[e-mail]>]

> -----Original Message-----
> From: Alissa Cooper [mailto:[e-mail]]
> Sent: Monday, December 14, 2015 1:49 AM
> To: Cullen Jennings
> Cc: Songhaibin (A); p2psip; [e-mail]
> Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 - crazy
> send math ....
> 
> 
> > 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?
> 

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
> >
> >
> >
> >
> >