Subject: [core] I-D Action: draft-ietf-core-observe-07.txt

From: [email-masked]
Date: Mon, 22 Oct 2012 12:32:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

	Title           : Observing Resources in CoAP
	Author(s)       : Klaus Hartke
	Filename        : draft-ietf-core-observe-07.txt
	Pages           : 28
	Date            : 2012-10-22

Abstract:
   CoAP is a RESTful application protocol for constrained nodes and
   networks.  The state of a resource on a CoAP server can change over
   time.  This document specifies a simple protocol extension for CoAP
   that enables a server to replicate a resource state to interested
   clients.  The protocol follows a best-effort approach when
   transmitting new resource states to clients, and provides eventual
   consistency between the state observed by each client and the actual
   resource state.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-observe

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-observe-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-observe-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 25 Oct 2012 09:45:17 +0000

Dear Klaus,
dear list

I read the new observe draft and a few questions popped up:

> 4.5.  Retransmission
>   When a notification is transmitted multiple times (either as caused
>   by a retransmission attempt or repeating it), the server MUST update
>   value of the Observe Option.  Otherwise, the client might discard the
>   notification as too old.

Why is this required for retransmissions (of the same state) at all? Either the client received the notification and updated its observe clock or it did not (and cannot discard it as old).
Or is this just intended for the case the server updates the state during an open CON transmission?
If I am missing the reason for this, I want to point out that this creates a messy dependency between all open transmissions, or requires one observe clock per client...

> 5.  Intermediaries
>   Because a client (or an intermediary in the client role) can only be
>   once in the list of observers of a resource at a server (or an
>   intermediary in the server role) -- it is useless to observe the same
>   resource multiple times -- an intermediary MUST observe a resource
>   only once, even if there are multiple clients for which it observes
>   the resource.

What about different content-types/accept options? An intermediary must be able to serve them if they are supported by the origin server. But if they cannot be converted, the intermediary can only use observing for one content-type.
Maybe the observe list entry should also be dependent on the content-type?

> 6.  Block-wise Transfers

So for observe, the server can send all blocks without the stop-and-wait mechanism?! Okay, this saves energy/messages and time, so why not do this for any blockwise transfer?
I would absolutely not do this because this is half way to TCP with its sliding window. A client would need a large buffer to store the whole body and must manage missing blocks. The whole point of CoAP's blockwise transfers is that the application can make use of fragments and for instance processes them on the fly. This is now broken, as the can arrive out of order and with gaps. Almost no advantage over 6LoWPAN fragmentation anymore...

This indirectly affects core-block, where I would also recommend in-order block transfers or at least the possibility for the receiver to enforce them.

What do you think?

Ciao
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2012 12:49:04 +0200

Hi Matthias,

let me try to answer this one:

On Oct 25, 2012, at 11:45, "Kovatsch  Matthias" <[email-masked]> wrote:

>> 6.  Block-wise Transfers
> 
> So for observe, the server can send all blocks without the stop-and-wait mechanism?! 

I think the operative text here is 

   suitably sequenced by its
   congestion control mechanism,

So stop-and-wait (or whatever is the advanced CC mechanism selected, if any) does continue to apply.
What can we do to say this in a less confusing way?

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 25 Oct 2012 11:57:58 +0000

Ah, I see. It was mainly the example figure that suggested notifications without ACKs/block requests.
So the client will decide which notification block to receive next?

Carsten Bormann <[email-masked]> wrote:

Hi Matthias,

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2012 14:14:30 +0200

> So the client will decide which notification block to receive next?

Unfortunately, we don't have a way to do this.
When the "initiative" (as I call it in the still not finished block-11) is with the server, it is the server that goes through the Block2 blocks.
(It's not that different in TCP :-)
But the client (the one receiving the notifications) still has to ACK them.
(Unless they are NON notifications, which I wouldn't really recommend using with -block.)
The ACK reduces the number of outstanding exchanges, triggering the next CON.
(Unless something like section 5.2 of draft-bormann-core-congestion-control-02.txt is in effect, but we aren't quite there yet, and we haven't decided how to negotiate/enable something like that, if it is really desirable.)

Grüße, Carsten