Re: [core] WG interest in Sleepy Node topic

"Pete St. Pierre" <pete.st.pierre@oracle.com> Wed, 11 December 2013 16:09 UTC

Return-Path: <pete.st.pierre@oracle.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DCA1AE04F for <core@ietfa.amsl.com>; Wed, 11 Dec 2013 08:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 yOXTG3jEIK2Z for <core@ietfa.amsl.com>; Wed, 11 Dec 2013 08:09:04 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 27A861AE03E for <core@ietf.org>; Wed, 11 Dec 2013 08:09:04 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rBBG8f0g019915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Dec 2013 16:08:42 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBG8dIi009156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 16:08:41 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rBBG8c2L009080; Wed, 11 Dec 2013 16:08:38 GMT
Received: from [192.168.1.9] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Dec 2013 08:08:38 -0800
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBECDC9D-AB16-4F04-BD79-5D6250BA54FA"
From: "Pete St. Pierre" <pete.st.pierre@oracle.com>
X-Priority: 3
In-Reply-To: <FEE43668972443B484ED4BFF923A3F80@WeiGengyuPC>
Date: Wed, 11 Dec 2013 08:08:38 -0800
Message-Id: <5E4E8105-A550-492D-85E4-A0AF283B441C@oracle.com>
References: <D60519DB022FFA48974A25955FFEC08C0561B74B@SAM.InterDigital.com><CAByMhx9aWkuDR397hYYNBVQCmz1v5XLvihuieTUQE3YPOZqZJA@mail.gmail.com> <B29BEB02-85AF-454C-A500-F5B6F01E9D6F@tzi.org> <FEE43668972443B484ED4BFF923A3F80@WeiGengyuPC>
To: weigengyu <weigengyu@bupt.edu.cn>
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Core <core@ietf.org>
Subject: Re: [core] WG interest in Sleepy Node topic
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 16:09:07 -0000

I agree with your assessment of #1 & #2. However, I don't think it is fair to assume in scenario #3 that network parameters can be assumed to remain unchanged. I've worked with devices that were used as you describe case #3, but when nodes awoke, they were highly likely to be in a different place with a different network environment. In many cases, a complete change of network was required (ie WiFi to 3G or Satellite).

Similarly, isn't a laptop a sleepy node? It sleeps when the lid is closed and doesn't reboot every time it is opened. However it frequently comes back on the network in a place where the network environment has changed. 

#3 may be true, but only if the node is 'sleepy' and stationary.
...Pete

On Dec 11, 2013, at 1:36 AM, weigengyu <weigengyu@bupt.edu.cn> wrote:

> Hi Carsten and all,
> 
> I think the Sleepy node problem is important, and CoAP mailing list seems to consider intermitent node currently.
> While, what is the sleepy node and what is the intermitent node?
> What network parameter are effected and what kind of networks needs concerning?
> 
> I would like to give what intermitent node (or intermitent endpoint) I concern.
> I think the intermitent indicates the following situations of CoAP endpoint:
> 1. the node will be power off and on, or reboot;
> 2. the node will go out and into the signal coverage, so the wireless commnication could be able and inable intermitently;
> 3. the node is into sleep mode in order to save power. Such a node might be the sleepy node you called.
>   Due to its inability to reponse the request, the sleepy node may be like the intermitent node.
>  In other words, the sleepy node is an intermitent node in nature in terms of communication ability intervals.
> 
> The  bootup process is required in the above cases 1, but not in the cases of 2 and 3.
> The network parameters , such as IP address, re-allocation is determined by the networks that the node accesses.
> 
> By Esko’ email, if the node is auto-configured by DHCP server, or the like,
> the node could get back network configured parameters whenever reboot.
> But this does not means that when rebooting the node saves the parameters itself enve though flash memory is embeded.
> The most typical network is WIFI.  When the mobile PC reboots,
> the DHCP server's parameters (option) determines whether to change the mobile PC's IP address.
> 
> The very different network is mobile 3G/4G, the mobile node will get new IP address in the case of 1 and  probably 2.
> The node in sleepy mode closes the data sending port and/or receiving port.
> The smart phone usually close both ports. (As a result signalling storm is apppeared in the mobile networks)
> This is case 3, and the node holds its network parameters. The communication ability will be delayed until the sleepy interval is expired.
> 
> Maybe the problem of configuration is out of CoAP scope,  and it is not clear what the CoAP endpoint enviroments have.
> Only the Resource Directory Server is depicted  and may function this in the given cases.
> 
> There is not a systematic processes defined to tackle sleepy or intermitent node.
> 
> So, the sleepy node I concerned is case 3; the intermitent node I concerned is case 1,2 and 3.
> 
> Regards,
> 
> Gengyu
> 
> Network Technology Center
> School of Computer
> Beijing University of Posts & Telecommunications.
> 
> 
> -----原始邮件----- From: Carsten Bormann
> Sent: Saturday, November 09, 2013 9:25 AM
> To: Thomas Fossati
> Cc: Core
> Subject: Re: [core] WG interest in Sleepy Node topic
> 
> On 08 Nov 2013, at 01:48, Thomas Fossati <tho@koanlogic.com> wrote:
> 
>> out of CoRE scope
> 
> At this stage of the discussion, I would be less concerned with the WG scope than with finding out what the industry actually needs to be standardized to foster interoperability.  If there are items within this set that are outside CoRE scope, we can always try to find a home for them, either by rechartering or by finding another WG.  But it is important to have a clear understanding of the items that we think need to be speced.  At a level a bit more specific than we have been discussing so far.
> 
> Grüße, Carsten
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core

--
Pete St. Pierre
Pete.St.Pierre@oracle.com
(650) 506-2152