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

Hi Akabr, 

> Okay, but I still don’t see the value of the third state (receive-only) from a CoAP point of view? 
Undestanding the benefit of receive-only state is not so difficult, the receiver can send one response in a bundle to a few requests if the protocol support. 

> I do understand it from a radio point of view, but that should perhaps be decoupled from CoAP application if there is nothing in CoAP that is explicitly impacted.
What I mean is that the current works related to sleepy nodes in CoAP WG considered only two mode. 
There are another working model in which the sleepy nodes have three modes. 

Leave it to  the applicatoin is an alternative, but seem  not to be good one.

Regards, 

Gengyu

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

From: Rahman, Akbar 
Sent: Wednesday, April 02, 2014 5:47 AM
To: weigengyu 
Cc: core@ietf.org 
Subject: RE: [core] draft-rahman-core-sleepy-05

Hi Gengyu,

Thank you for your feedback.  

>If the sensor has registered its sleepy mode, the proxy could give this knowledge to the client in the response. 

>The Content within the response may be extended to cover three-state server.

Okay, but I still don’t see the value of the third state (receive-only) from a CoAP point of view?  I do understand it from a radio point of view, but that should perhaps be decoupled from CoAP application if there is nothing in CoAP that is explicitly impacted.

Akbar

From: weigengyu [mailto:weigengyu@bupt.edu.cn] 
Sent: Tuesday, April 01, 2014 11:57 AM
To: Rahman, Akbar
Subject: Re: [core] draft-rahman-core-sleepy-05

Hi Akbar, 

>>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.

>This is interesting.  But, what is the main benefit of the receive-only mode?  

I have just got the requirements of two-state server and three-state server. 

The receive-only may save power compared to active mode.

The sensor works in a fixed interval and can give responses at a time.  

>That is, since the CoAP model is request/response, what is the value of being able to send the request (e.g. GET) without knowing the response?

The first request from the client does not know this. The client send “GET” as usual.

Without the sensors registration information, the proxy treat it as a mormal request.

If the sensor has registered its sleepy mode, the proxy could give this knowledge to the client in the response. 

The Content within the response may be extended to cover three-state server.

>>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 –After”. 

>Is “Waiting for a while” a new CoAP Response code that needs to be defined?

I think “The Retry -After” means “wait for a while and then retry.” 

So, the extension is to provide whether “wait for a while” or “wait for a while and then retry.” 

It could be a new response code. 

Regards, 

Gengyu

Network Technology Center

School of Computer

Beijing University of Posts and Telecommunications

From: Rahman, Akbar 

Sent: Monday, March 31, 2014 8:27 PM

To: weigengyu 

Cc: core@ietf.org 

Subject: RE: [core] draft-rahman-core-sleepy-05

Hi Weigengyu,

Thank you for the good questions.  Following is my feedback:

>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 –After”. 

Is “Waiting for a while” a new CoAP Response code that needs to be defined?

>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.

This is interesting.  But, what is the main benefit of the receive-only mode?  That is, since the CoAP model is request/response, what is the value of being able to send the request (e.g. GET) without knowing the response?

Best Regards,

Akbar

From: weigengyu [mailto:weigengyu@bupt.edu.cn] 
Sent: Monday, March 31, 2014 5:57 AM
To: Rahman, Akbar
Cc: core@ietf.org
Subject: Re: [core] draft-rahman-core-sleepy-05

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 –After”. 

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