IETF Logo Mail Archive

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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Tue, 08 December 2015 16:10 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B271B2F76 for <p2psip@ietfa.amsl.com>; Tue, 8 Dec 2015 08:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.511
X-Spam-Level:
X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVa19gwN-uc4 for <p2psip@ietfa.amsl.com>; Tue, 8 Dec 2015 08:10:05 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5121B2DC0 for <p2psip@ietf.org>; Tue, 8 Dec 2015 08:10:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1449591005; x=1450800605; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v4J3ow0ryvpyhArQlGqrA1CC55WOiW9IWsWIUFKaIdA=; b=V56WKuHnYu6iRBsJfF5xEWIdSL3CvzpntywDKx8XvcwsswO8zZSR3VHi BpQUqI1T+99/i7gbE8a0OC+OMXlxqTy4jHRobWQhma5r1kbNFm8k3+fKx 4R/JJIkM+eXt6jw8M2L3VTZP/qWXeoo7W7cij1T1/P3NqxasF+Vcv+9k1 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CFAwCJ/2ZW/49dJa1eKAECgw+BQQasJJEUAQ2BboYOAoE+OBQBAQEBAQEBgQqENAEBAQMBOj8FCwIBCBgeEDIlAgQBDQWIJwjAXgEBAQEBAQEBAQEBAQEBAQEBAQEBARiIY4JuhFmDTYEVBZJ3g2oBjTucbAEfAQFCgg4gFoFAcoRogQcBAQE
X-IronPort-AV: E=Sophos;i="5.20,400,1444694400"; d="scan'208";a="214619605"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2015 16:10:04 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tB8GA4f2021560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Dec 2015 16:10:04 GMT
Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Dec 2015 11:10:04 -0500
Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Tue, 8 Dec 2015 11:10:03 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Alissa Cooper <alissa@cooperw.in>, "Songhaibin (A)" <haibin.song@huawei.com>
Thread-Topic: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 - crazy send math ....
Thread-Index: AQHRMdLlLXzfUXoo90WwuYc1zixg4A==
Date: Tue, 08 Dec 2015 16:10:03 +0000
Message-ID: <4541D978-85FB-483A-A66C-F8D22D8619F7@cisco.com>
References: <37059182-6C51-49E3-83A0-D27F2C15A366@cooperw.in> <CADqQgCQ_hEacxApiauKLYD0Y+ahkXGDi9uXFvLN1XjqLpzjh0Q@mail.gmail.com> <5C131A2D-2519-4CD5-AAB0-1E01563C9665@cooperw.in> <E33E01DFD5BEA24B9F3F18671078951F65345644@nkgeml501-mbs.china.huawei.com> <B30B3C53-F230-4607-878F-12BFBBE2D277@cooperw.in> <EE06F5C7-0499-49A1-86A7-2234C54D3EB1@cooperw.in> <E33E01DFD5BEA24B9F3F18671078951F653A9E39@nkgeml501-mbs.china.huawei.com> <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in>
In-Reply-To: <52C1D77C-4E21-4C1B-A16E-D20B638B38FF@cooperw.in>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D98235810C08EB4B8EEBFD8786CD5B41@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/GTME5bSyXQ1v-t0M9CFEsFp9oJk>
Cc: p2psip <p2psip@ietf.org>, "draft-ietf-p2psip-diagnostics@tools.ietf.org" <draft-ietf-p2psip-diagnostics@tools.ietf.org>
Subject: Re: [P2PSIP] AD evaluation: draft-ietf-p2psip-diagnostics-17 - crazy send math ....
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 16:10:07 -0000

> On Nov 11, 2015, at 4:09 PM, Alissa Cooper <alissa@cooperw.in> 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

v2.23.0 | Report a Bug | By Email