Subject: Re: [core] CoAP over TCP: Extending the shim Header Payload

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Apr 2016 17:59:38 +0200

Hi Carsten, Hi all,

I am trying to follow-up on this topic.

From the discussion at the last IETF meeting I believe we agreed that we
want to explore the concepts described below. Is that true?

I have re-read your write-up below and my earlier understanding was that
we have to add another short shim header field to distinguish a CoAP
packet from something else. You seem to have a different view about
this, if I interpret it correctly.

Re-using CoAP sounds like a good idea but also means that we are
overloading the semantic of CoAP payloads an messages. Do we want that?

Just selecting two of the features Klaus has raised.

1) Error Handling: Server returns a message that it was unable to
process the message (for example, due to an incorrect message length)

                        Client              Server
                           |                  |
                           | <--- TCP  --->   |
                           | Connection Setup |
                           |                  |
                           |   NON            |
                           | GET /temperature |
                           |   (Token 0x74)   |
                           +----------------->|
                           |                  |
                           |   NON            |
                           |   4.00 Code      |
                           |   (Token 0x74)   |
                           |<-----------------+
                           |                  |
                           | <--- TCP --->    |
                           | Conn. Teadown    |

Here the question is how we can indicate that the error message actually
does not refer to the initial CoAP request but rather indicates the
inability of the server to process the request at all. It just happens
to provide the response in a CoAP-based format.

I picked an error code from the available range that feels appropriate.

2) Server Name Indication: Client provides the SNI (i.e., a HostName) to
the server.

                        Client              Server
                           |                  |
                           | <--- TCP --->    |
                           | Connection Setup |
                           |                  |
                           |   NON            |
                           | GET /temperature |
                           |   (Token 0x74)   |
                           |+ SNI: example.com|
                           +----------------->|
                           |                  |
                           |   NON [0x23bc]   |
                           |   2.05 Content   |
                           |   (Token 0x74)   |
                           |     "22.5 C"     |
                           |<-----------------+
                           |                  |
                           |      ......      |
                           |   time passes    |
                           |      ......      |
                           |                  |
                           |  <--- TCP --->   |
                           |  Conn. Teadown   |

How does this approach look like?

Ciao
Hannes

On 03/30/2016 09:06 PM, Carsten Bormann wrote:
> I didn't write this up yet, but it seems I'll have to.
> 
> Any extension to the shim header will soon grow into a protocol that is
> as complex as CoAP itself.
> 
> Instead, we should simply re-use a protocol that we already have: CoAP.
> 
> (If we really need to do all of this; I'm not convinced yet.)
> 
> See below for how (I haven't checked the details against your new
> protocol, but it's the gist I'm after here).
> 
> Grüße, Carsten
> 
> 
> 
> # Signaling messages
> 
> Signaling messages are structured like any other CoAP message; they
> have a code, a token, options, and optionally a payload.
> The code for a signaling message comes from the 7.xx space.
> 
> Option numbers for signaling messages are specific to the message
> code, i.e., they do not share the number space with CoAP options for
> request/response messages or with signaling messages using other
> codes.
> Signaling options can be elective or critical; if a signaling message
> option is critical and not understood by the receiver, it MUST abort
> the connection.  (If the option is understood but somehow cannot be
> carried out, the option defines how to handle the error.)
> 
> Payloads in signaling messages are diagnostic payloads, unless
> otherwise determined by a signaling message option.
> 
> Five types of signaling messages are defined:
> 
> * Capability messages: indicate a capability to the peer.  Most
>   capability options will be elective.  Capability indications are
>   cumulative, i.e., a capability message without any option is a
>   no-operation (and can be used as such).  (An option that is given
>   might override a previous value for the same option; the option
>   defines how to handle this, if needed.)  Most options are defined
>   only for the first message in the connection.
> 
> * Ping, pong: A ping message is responded to by a pong message with
>   the same token.  No options are defined for Ping messages in this
>   specification, but options might be defined later.  As with all
>   signaling messages, the receiver of a ping or pong message MUST
>   ignore elective options it does not understand.
> 
> * Release.  A release message indicates that the sender does not want
>   to continue maintaining the connection and opts for an orderly
>   shutdown; the details are in the options.  A release message will
>   normally be replied to by a release message as soon as possible by
>   the receiver; only then is the connection closed.  (To do: define
>   who actually closes the TCP connection.)
> 
> * Abort.  An abort message indicates that the sender is unable to
>   continue maintaining the connection and cannot even wait for an
>   orderly release; the sender shuts down the connection immediately
>   after the abort (and may or may not wait for a release or abort
>   message in the inverse direction).
> 
> Release and abort messages indicate one or more reasons using elective
> options.
> 
> ## Discussion
> 
> Capability messages remove the perceived need for versioning.
> (Versioning is great for keeping incompatible implementations from
> accidentally trying to talk to each other, but is not a good
> evolution strategy.)
> 
> An effect similar to the ping/pong message can be achieved by creating
> a resource that has appropriate no-operations semantics (e.g., returns
> an empty payload on a GET or returns the payload given on a POST).
> Handling the function as a signaling message keeps the resource name space
> clean of such resources.
> 
> The need for orderly release only becomes apparent in the presence of
> non-idempotent requests such as POST.
> It does not solve the problem that a connection that breaks in an
> uncontrolled way keeps the status of that request unclear.
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Apr 2016 18:23:39 +0200

> want to explore the concepts described below. Is that true?

I think so.  With an emphasis on "explore" -- we don't have to do
everything that comes to mind.

> this, if I interpret it correctly.

Right, there is no need to bloat up the header again because we can use
the code field for that.

> overloading the semantic of CoAP payloads an messages. Do we want that?

There is no overloading, as signaling messages are clearly distinct from
request/response messages.  They just share the same encoding, so we
have less invention and less implementation work.

> How does this approach look like?

Well, we define signaling messages for settings and error messages.

Note there is very little point in elaborate handling of encoding errors
(such as incorrect message lengths), these are just there for debugging
and can therefore be the diagnostic payloads of an otherwise very simple
signaling message (section 5.5.2 of RFC 7252).  More interesting is an
indication of the reason for orderly release (e.g., a node might want to
know whether the other node is OK with re-establishing the connection
now or later), here we probably want to define different messages and/or
options/option values to enable programmatic handling of these cases.

Do we have an idea of what settings we want to provide?
These could be
1) capability indications (probably the majority of the cases), e.g.:
   a) can handle messages larger than 1152 bytes (and how large)
   b) can do BERT
   ...
2) actual settings, such as SNI or default Uri-Host.

Grüße, Carsten