[core] CoAP over TCP

[Carsten Bormann <[e-mail]>]

In alternative transports, I believe we have three hot topics:

1) General issues.  draft-silverajan-core-coap-alternative-transports is a good basis for this and we will do the call for adoption soon.

2) CoAP over SMS.  This is also related to the question of DTLS over SMS.  We have a good draft for the former, which is mostly waiting for (1).  draft-fossati-dtls-over-gsm-sms merits some discussion.

3) CoAP over TCP.  draft-bormann-core-coap-tcp-01 is a summary of the design choices. draft-tschofenig-core-coap-tcp-tls selects one option without explaining why.  draft-savolainen-core-coap-websockets (apart from being focused on web sockets, so it would need the addition of a length field) selects a different set of options, also not really explaining why.  This merits a discussion.

I believe we should have a quick round of discussion about (3).  CoAP over TCP is of strong interest to people building scalable cloud-side CoAP implementations.  CoAP over TCP also is a NAT traversal strategy (where the server builds the connection to a client in the cloud).  Finally, CoAP over TCP can be useful to combine the better congestion control of TCP with the economy of CoAP.  So there are enough reasons to get this going.

The main questions I see are:

a) what is the delimiting mechanism?
   — length field
     — fixed 4-byte, fixed 2-byte, variable?
   — MINION-style (delimiters)
   — extending the payload marker
b) what part of the CoAP header remains active over a reliable transport?  Can we lose
   — the message id,
   — the message type,
   — the version number?
c) any negotiation/version indication mechanisms?
   — starttls???
   — server/client prompts
   — ALPN
   — other payloads, e.g. stream errors?

Grüße, Carsten