Subject: [core] #1: Agree on Sub/Not model and requirements

From: "core issue tracker" <[email-masked]>
Date: Fri, 11 Jun 2010 09:18:10 -0000

#1: Agree on Sub/Not model and requirements
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  Cullen Jennings <fluffy@…>        
     Type:  task                |      Status:  new                               
 Priority:  critical            |   Milestone:                                    
Component:  coap                |     Version:                                    
 Severity:  -                   |    Keywords:                                    
--------------------------------+-------------------------------------------
 The working group has intensely discussed detailed solutions for
 Subscribe/Notify, however Cullen pointed out that we didn't yet have a
 common understanding of the model to use and the requirements. This ticket
 is for the WG to converge on the general model and requirements. After
 this a new design based on that model and requirements will be included in
 draft-ietf-coap-01.

 Cullen started this important thread here:
 http://www.ietf.org/mail-archive/web/core/current/msg00274.html

 The goal of this ticket is to have a short I-D capturing this model and
 requirements.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/core/trac/ticket/1>
core <http://tools.ietf.org/core/>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jun 2010 13:42:42 +0200

> common understanding of the model to use and the requirements

(Posting as an individual member of the WG.)

While discussing this here with a student, we noticed that the usual model for doing asynchronous notification in HTTP, i.e. long-poll, does not work in CoAP.

When a client requests the representation of a resource and the server does not immediately respond, the client will retransmit.

To make long-poll (or any kind of response that takes more than RESPONSE_TIMEOUT) work, we would need to have a provisional response (100-style, if you have the SIP scars).
This would stop the client from retransmitting, but shift the burden to the server:
In turn, the actual response would need an acknowledgement (and thus an A-bit) to make sure it doesn't just get lost.

In the end, a delayed response looks very close to what is called "notify" in CoAP-00.
Once that problem is addressed, it seems as if a SUBSCRIBE might look very close to a GET.
We are currently discussing how to get a more REST-like version of SUBSCRIBE defined on this basis.
(We are calling that method OBSERVE.  Both GET and OBSERVE will elicit responses, some of which are immediate and some are happening later.)

I'd like to move some of the discussion to who maintains conversation state.
For the server, REST is stateless on the application layer (i.e., all state is in the resources, not in the conversation).
That is no longer true when you look at the transport layer: opening a TCP connection creates conversation state in the server.
The fact that POST is not idempotent is only tolerable because a POST is supported by the TCP conversation state.

One objective I have in mind is to minimize the negative effects of the conversation state.
It will be impossible to completely avoid any conversation state in our domain (e.g., in 6LoWPAN, we definitely will have to reassemble at the adaptation layer -- this is also conversation state, and it is really hard to manage properly).
Shifting conversation state down the stack is generally *not* a good solution; it usually just makes the problem worse (only when it doesn't can we really reap benefits off the separation of concern layering gives us).
Shifting certain conversation state up into the resources *may* be a good solution (this strategy helps making REST successful in the existing Web, e.g., think session objects).

So my questions are:
1) Which conversation state is tolerable, which state do we want to avoid?
2) How can we avoid conversation state?
3) What do we have to do to make the conversation state we do need less fragile?
(E.g., how can we make sure eventual convergence as opposed to just deadlocking/dropping the ball?)

(While these questions may sound complex, the protocol that will result from the right answers will be very simple.)

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 11 Jun 2010 16:08:20 +0200

I share your concerns about conversation state/session handling. TCP
has really simplified the design of  HTTP, using UDP leads to a more
complex design. In general using a transport layer providing a
reliable, full-duplex stream session helps a lot.

In my opinion, all the functionalities included in CoAP doesn't need
to retain any state, except subscription/delayed replies (on the
delayed GET topic look here
http://www.ietf.org/mail-archive/web/core/current/msg00282.html and
http://www.ietf.org/mail-archive/web/core/current/msg00278.html).
However transport state is still required by every interaction.

The real problem here is to understand how to solve transport related
problems without defining a new transport protocol (which is probably
needed to efficiently design CoAP).

Best,
Angelo

On Fri, Jun 11, 2010 at 13:42, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 11 Jun 2010 22:30:09 +0200

> However transport state is still required by every interaction.

Why?

> needed to efficiently design CoAP).

Why do you believe a new transport protocol would help?
As I said, I don't believe pushing the state down a layer solves any problem.

Gruesse, Carsten

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 14 Jun 2010 11:01:14 +0200

A CoAP server has to track at least every received non-idempotent CoAP
request for a time long enought to avoid to interpret a retransmission
as a new request. In general a CoAP server should track every request
to avoid handling every retransmission as a new request (inefficient)

A CoAP client has to track and handle retransmissions of every sent
request requiring ACK and/or response, otherwise it has only to wait
for the response event or for a timeout event.

CoAP subscription architecture using subscribed-GET will be very
simple with a transport session established by a lower level module,
as discussed in the messages I referenced in my last message.

State informations to be tracked by CoAP are really transport
dependant and maybe beneficial to implement that features in a
separate module, which can be also shared with other protocols.

TransactionID is not needed using TCP or DTLS, using UDP can be almost
everytime replaced by the client source port (a transactionID option
can be defined for those rare cases where TID is really useful).

If a viable transport protocol providing reliability is defined,
transactionID will not be needed anymore.

Best,
Angelo

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 29 Jun 2010 07:31:50 -0000

#1: Agree on Sub/Not model and requirements
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  Cullen Jennings <fluffy@…>        
     Type:  task                |       Status:  closed                            
 Priority:  critical            |    Milestone:                                    
Component:  coap                |      Version:                                    
 Severity:  -                   |   Resolution:  fixed                             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 draft-hartke-coap-observe-00 captures the overall architecture and
 requirements for asynchronous CoAP interactions. This satisfies the goal
 of this ticket well.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/1#comment:1>
core <http://tools.ietf.org/core/>

---

From: Paul Duffy <[email-masked]>
Date: Tue, 29 Jun 2010 09:59:58 -0400

What exactly does this mean, that the "model and requirements" for 
sub/not are settled?

On 6/29/2010 3:31 AM, core issue tracker wrote:
>   Reporter:  zach@…              |        Owner:  Cullen Jennings<fluffy@…>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 29 Jun 2010 17:08:56 +0300

The goal of this ticket was to document what the actual architecture and requirements for the interaction model are. This draft did a good job of that part. 

The solution we need to look at separately in Ticket #2. Carsten will an idea for a way forward for a solution later today. Although we do now think it will be possible to do this in a way that makes this possible without adding new REST methods thanks to some improvements to the asynchronous interaction we're working on for coap-01. The key was to better separate the transaction from the REST transfer (see the mail I sent yesterday on the list regarding that).

Zach

On Jun 29, 2010, at 4:59 PM, Paul Duffy wrote:

> What exactly does this mean, that the "model and requirements" for sub/not are settled?
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297