Subject: [core] CoAP-TCP-TLS: Proposal for more adapter type approach

From: Lauri Piikivi <[email-masked]>
Date: Tue, 28 Jun 2016 05:53:44 +0000

Hi alls,

I would like to suggest some alternatives for the TCP and TLS adaptation of COAP below, based on the draft-ietf-core-coap-tcp-tls-02.
To me it is a bit overly complex, and could be streamlined for easier implementation at the cost of a few bytes in transit. My main concern is the  reuse of existing COAP (UDP) implementations with minimal and easy to maintain changes.

My first concern on the resend / message ID logic on TCP. Keeping the message ID in the messages would mean that the COAP implementation logic does not depend so much on the transport. Same message could be send, and resending behaviour stays the same (although on TCP it would be extremely rare). If no acknowledgement is wanted, the non-confirmable message can be used, as the explicit choice of the developer.

As I would like to see the RFC 7252 COAP message structure intact as much as possible, I would propose a more wrapper like approach than in the current draft.  My main concern is that it is not really a message adapter as shown in Figure 1. The message structures are changed, for 3 different formats depending on the message length (original COAP in figure 4 versus figures 6, 8, 9)
I see 2 alternatives to make this a bit more clear, and keeping the message parsing as much as is for the COAP:
A) (D)TLS type record layer: the original COAP message is preceded by a structure with the message length. Also a version for the wrapping could be possible. So the records would always be used, on top of TCP. And maybe a magic byte to verify the structure. This is a more true wrapper approach as in Figure 2
- 5 bytes minimum (+proposed storing of message ID) = cost is 7 bytes in transmission medium
B) it could be possible to keep COAP message as defined in RFC 7252, and define a new option for message length and signals  a reliable stream transport like TCP. This is similar to HTTP operation, where the Content-length is defined in the headers, indicating the parser how long the message is
- 2-5 bytes, if wanting to optimise so that the option length differs for the different message lengths

Either approach would keep the implementation logic more inline with the current UDP COAP approaches. It could reduce errors, streamline the implementation, and save implementation memory (with less configuration issues).

(I have tried sending this mail before, however it does not seem to be in the archives or anywhere, so maybe it was lost. Apologies if you reread this)

Respectfully,
- Lauri Piikivi
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Jun 2016 08:43:22 +0200

Lauri Piikivi wrote:
> As I would like to see the RFC 7252 COAP message structure intact as much as possible,

Why?

I don't think that running the full RFC 7252 message layer (with
timer-based retransmission) on top of TCP is a very meaningful exercise.
 Two retransmission engines racing each other never has worked very well
in the history of protocol design.

Grüße, Carsten

---

From: Lauri Piikivi <[email-masked]>
Date: Tue, 28 Jun 2016 07:00:52 +0000

Hi,

my main concern is that there are devices with TCP and UDP transports (depending on the underlying network) and we end up with very different COAP implementation “flavours” and COAP implementation complexity for the different transports.

Timeouts problem is a good point. Implementation wise it might be easier to define that the timeout is much longer on top of TCP transport?

Sincerely
- Lauri Piikivi

> On 28 Jun 2016, at 09:43, Carsten Bormann <[email-masked]> wrote:
>
> Lauri Piikivi wrote: