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 <mailto:weigengyu@bupt.edu.cn>  

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