Re: [core] draft-rahman-core-sleepy-05

"weigengyu" <weigengyu@bupt.edu.cn> Mon, 31 March 2014 09:57 UTC

Return-Path: <weigengyu@bupt.edu.cn>
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 494B91A0988 for <core@ietfa.amsl.com>; Mon, 31 Mar 2014 02:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Veqvh_x4KTnd for <core@ietfa.amsl.com>; Mon, 31 Mar 2014 02:57:28 -0700 (PDT)
Received: from mx1.bupt.edu.cn (mx1.bupt.edu.cn [211.68.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7C31A0820 for <core@ietf.org>; Mon, 31 Mar 2014 02:57:27 -0700 (PDT)
Received: from WeiGengyuPC (unknown [10.103.244.154]) by mx1.bupt.edu.cn (AnyMacro(G7)) with ESMTPA id 1FA7519F372; Mon, 31 Mar 2014 17:57:22 +0800 (HKT)
Message-ID: <24D85E520FCE4FD0AF1A451A102FA5FB@WeiGengyuPC>
From: weigengyu <weigengyu@bupt.edu.cn>
To: Akbar.Rahman@InterDigital.com
References: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC>
In-Reply-To: <146BA183A28B4C6DBF8EA90D49B5724C@WeiGengyuPC>
Date: Mon, 31 Mar 2014 17:57:21 +0800
Organization: BUPT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CF4D0A.A9F10370"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3522.110
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110
Archived-At: http://mailarchive.ietf.org/arch/msg/core/B8zVVTXBx4NT8Qxq3g6bBCYmAM0
Cc: core@ietf.org
Subject: Re: [core] draft-rahman-core-sleepy-05
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: Mon, 31 Mar 2014 09:57:31 -0000

Hi Akbai, 

I would like to make my question clear.

In your work, ¡°Enhanced Sleepy Node Support for CoAP IETF 87, July 2013, Sleepy Node Performance Analysis¡±
in the PPT page of ¡°Reverse Proxy Features for Sleepy Node Support¡± 
there are following descriptions: 
¡°Sleep-aware CoAP 5.03 Response Capability 
If CoAP request to a sleeping server is received (and there is no valid cache for that request), proxy returns a ¡®5.03 Retry-After¡¯ response to client  
5.03 contains a timestamp indicating when the sever will wake back up (timestamp delivered in CoAP maxAge option) ¡° 

In our researching work, the CoAP server has three working modes: active, receive-only, and sleep.
active mode: the server can send and receiv;
receive-only mode: the server can receive, not send;
sleep mode: the server can neither send nor receive.

So, in the situation when the CoAP server is in receive-only mode, the proxy should forward the request to the server. 
The CoAP server could receive the request and give a  response after a while. 
The proxy need to return ¡°Waiting for a while¡± instead of ¡°The Retry ¨CAfter¡±. 

This may be due to how we define the sleepy node. 
And, the requirement is to consider three working modes of CoAP server when handling sleepy nodes. 

if the CoAP Client get this knowledge it may be good to get better the communication efficiency in CoRE networks.

Regards, 

Gengyu 

Network Techonolgy Center
School of Computer
Beijing University of Posts and Telecommunications

From: weigengyu 
Sent: Friday, March 28, 2014 11:03 AM
To: Akbar.Rahman@InterDigital.com 
Cc: core@ietf.org 
Subject: Re: [core] draft-rahman-core-sleepy-05

Hi Akbar,

About draft-rahman-core-sleepy-05 Enhanced Sleepy Node Support for CoAP, I have a question. 

Defining Sleep Para to tackle sleep nodes in CoRE networks is an essential work and important. 

By the Figure 3: Prototype Configuration,
you propose to add RD Sleep Para into proxy (CoAP Reverse Proxy). 

Is it possible to transfer Sleep Para into CoAP Client? 
It is the CoAP Client to intial each CoAP request,  
and the CoAP Client may get the infomations about the resources from the ACK of the first access, if possible. 

With this knowledge, the CoAP client could choose the adquate chance to send request, 
and estimate the duration to wait for response.  


Regards,

Gengyu

Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications.



--------------------------------------------------------------------------------
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core