I think this actually leads to a broader discussion/question of where we document and list all the things that we may want to monitor vs. the mechanisms used to collect/monitor them.
How do we as a group want to manage the definitions of these various diagnostic information pieces? Now of course we can register the actual codes for them with IANA, but do we try to capture a large number and define in the diagnostic draft? We need to document somewhere what the information associated with the registration BATTERY (or whatever) means. Do we only specify in the diagnostic draft how to get them (i.e., mechanism only), and use some other document/system to define the various fields we track? There is one set of technical questions about *how* we do diagnostics, and another about *what* we want to be collected/monitored. I'd love to hear thoughts on this...I'm not sure what the best plan is yet, still trying to get my head around the question. David (as individual) On Thu, Jul 30, 2009 at 2:40 PM, Erkki Harjula<[email protected]> wrote: > The problem with expressing the remaining uptime is the difficulty of > defining it. Remaining battery percentage is easy and universal method > without any estimation inaccuracy. > > On the other hand, a boolean value telling whether the node is running on > batteries may be enough. If you think about the energy consumption from the > user's perspective, he/she is usually interested of it only when his/her > device is running on its batteries. Energy saving is important from the > first second the device is unplugged from external power source, not only > when the battery nearly empty. > > -Erkki > > > Song Haibin wrote: >> >> Yes. The difficult thing of including battery status as one kind of >> diagnostic information is how you define it. I think Saumitra's comment >> (remaining uptime from the perspective of battery) makes sense. >> Could you please list all the diagnostic information kinds that are not >> clear in your mind? So that we can try to fix the definition. >> >> Thanks, >> Haibin >> >> >> ----- Original Message ----- From: "Das, Saumitra" <[email protected]> >> To: "jc" <[email protected]>; "Erkki Harjula" <[email protected]> >> Cc: "'P2PSIP WG'" <[email protected]> >> Sent: Thursday, July 30, 2009 11:18 AM >> Subject: Re: [P2PSIP] Battery status information to diagnostics draft >> >> >> >>> >>> While this seems a useful option to have to build better overlays; we >>> should use something that reflects the estimated remaining uptime based on >>> energy remaining of a device which is more relevant to overlay operations. >>> Just energy information may be ambiguous. From a diagnosis point of view we >>> cannot deduce what it means. >>> >>> I still think the diagnostic kinds are not defined fully. It wont be very >>> useful if each implementation has its own notion of defining bandwidth, >>> processing power etc. Some more explanantion of the kinds would be very >>> useful. >>> Thanks >>> Saumitra >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >>> Of jc >>> Sent: Wednesday, July 29, 2009 12:14 PM >>> To: Erkki Harjula >>> Cc: 'P2PSIP WG' >>> Subject: Re: [P2PSIP] Battery status information to diagnostics draft >>> >>> IMHO, this should be a binary value representative of the % of energy a >>> device may have available at any given time. This covers solar, wind, etc >>> and not simply "battery" as far as terminology is concerned. Who's to say a >>> solar based geo-sync satellite might not be running as a p2psip node one >>> day with battery backup on board? ;-) >>> >>> jc >>> >>> On Jul 29, 2009, at 4:40 AM, Erkki Harjula wrote: >>> >>> >>>> >>>> Hi, >>>> >>>> as requested in P2PSIP session yesterday, I restate here on the list my >>>> comment regarding battery status information. >>>> >>>> I think including battery status information would be useful to include >>>> in the draft. It would be useful e.g. in peer/client mode decision or load >>>> balancing, where battery status information could be used to relieve the >>>> load of those nodes running on batteries (just two examples among many >>>> others!). As everybody knows, more and more devices nowadays, especially >>>> in >>>> P2PSIP scenarios, are battery operated. >>>> >>>> The status info could be the remaining battery percentage, or simply a >>>> binary value telling whether the node is running on its batteries or not. >>>> >>>> -Erkki >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
