Subject: [P2PSIP] changes to the p2psip diagnostics draft

From: Song Haibin <[email-masked]>
Date: Wed, 08 Jul 2009 12:04:30 +0800

Hi,

We have removed the ECHO method in version 01 due to secruity considerations
raised in the mailing list and SF meeting. The diagnostics information in
the base draft has been merged into the document. We also changed the table
of contents and define extensible diagnostic flags. Please read the document
and we will be glad to receive more comments as input.

http://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-01

Best Regards,
Haibin
Skype: alexsonghw

---

From: Erkki Harjula <[email-masked]>
Date: Wed, 29 Jul 2009 13:40:40 +0200

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

---

From: jc <[email-masked]>
Date: Wed, 29 Jul 2009 12:14:00 -0700

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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Das, Saumitra" <[email-masked]>
Date: Thu, 30 Jul 2009 02:18:28 -0700

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-masked] [mailto:[email-masked]] 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

jc

---

From: Song Haibin <[email-masked]>
Date: Thu, 30 Jul 2009 12:58:51 +0200

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

---

From: Erkki Harjula <[email-masked]>
Date: Thu, 30 Jul 2009 14:40:00 +0200

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

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 30 Jul 2009 18:39:10 +0200

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-masked]> wrote:
> 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-masked]>
>>> 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
>>>
>>> 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
>>>
>>>> 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.
>>>>