Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17

From: "Songhaibin (A)" <[email-masked]>
Date: Thu, 3 Dec 2015 01:51:01 +0000

Could some authors of the RELOAD RFC answer this question? As it was merged from the RELOAD draft. Although we can discuss without them.

Best Regards!
-Haibin

From: Alissa Cooper [mailto:[email-masked]]
Sent: Tuesday, December 01, 2015 4:06 AM
To: Songhaibin (A)
Cc: p2psip; [email-masked]
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17

Thanks. Last call has been initiated. Still looking for answers below.

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?

Alissa

On Nov 26, 2015, at 6:25 PM, Songhaibin (A) <[email-masked]<mailto:[email-masked]>> wrote:

Dear Alissa,

I have submitted a new version with changes to the diagnostic information authorization part, and leave the  EWMA_BYTES_SENT and EWMA_BYTES_RCVD for discussion during IETF last call.

Best Regards!
-Haibin

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 8 Dec 2015 16:10:03 +0000

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

---

From: Alissa Cooper <[email-masked]>
Date: Sun, 13 Dec 2015 09:48:58 -0800

> On Dec 8, 2015, at 8:10 AM, Cullen Jennings (fluffy) <[email-masked]> wrote:
> 
> 

Thanks Cullen.

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

Alissa

---

From: "Songhaibin (A)" <[email-masked]>
Date: Mon, 14 Dec 2015 01:05:51 +0000

> -----Original Message-----
> Sent: Monday, December 14, 2015 1:49 AM
> To: Cullen Jennings
> Cc: Songhaibin (A); p2psip; [email-masked]
> Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 - crazy
> send math ....
> 
> 
> >>> 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?
> >>> [Haibin] This is incorporated from the early RELOAD document. Maybe
> some author of the RELOAD protocol can give a better explanation.
> >>
> > 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.
> 

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