Subject: Re: [core] CoAP over TCP

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Nov 2014 10:24:49 -1000

One more data point that came up in the APPAREA WG this morning:

Sam Ruby has now started an effort to find out how URI parsers actually behave.
I’m not sure that is the best link, but if interested maybe you can start looking at
http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI

Grüße, Carsten

> On 24 Oct 2014, at 06:11, Carsten Bormann <[email-masked]> wrote:
> 
> 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
> 
> 
>

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 10 Nov 2014 21:32:27 +0000

Hi Carsten,

I wasn¹t aware that CoAP would exist (in any significant way) ³outside² of
constrained environments ‹ I¹ve been thinking HTTP<->CoAP gateways at the
edge of a constrained environment - only using ³CoAP² where the ³Co²
requirement exists.  I¹m assuming CoAP in the cloud would only be for
³IoT-only² services ?

Thanks!
Randy

On 11/10/14, 3:24 PM, "Carsten Bormann" <[email-masked]> wrote:

>I¹m not sure that is the best link, but if interested maybe you can start
>looking at
>> 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.
>>
>>   ‹ length field
>>     ‹ fixed 4-byte, fixed 2-byte, variable?
>>   ‹ MINION-style (delimiters)
>>   ‹ extending the payload marker
>>   ‹ the message id,
>>   ‹ the message type,
>>   ‹ the version number?
>>   ‹ starttls???
>>   ‹ server/client prompts
>>   ‹ ALPN
>>   ‹ other payloads, e.g. stream errors?
>>
>> Grüße, Carsten
>>
>>
>>
>
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Nov 2014 00:33:03 +0100

Hi Carsten,

thanks for the write-up.

On 10/24/2014 06:11 PM, Carsten Bormann wrote:
> SMS.  We have a good draft for the former, which is mostly waiting
> for (1).  draft-fossati-dtls-over-gsm-sms merits some discussion.

Thanks for mentioning draft-fossati-dtls-over-gsm-sms; I am happy to
briefly describe what we had been working on.

> without explaining why.

draft-tschofenig-core-coap-tcp-tls describes what we (ARM and Zebra)
have implemented and deployed.

Our use case is firewall traversal in enterprise networks. Our goal was
to use our existing CoAP over UDP implementation. Doing optimizations to
CoAP when we already add all the complexity of TCP didn't seem
worthwhile to us.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Nov 2014 14:01:10 -1000

Hi Randy,

indeed, CoAP is designed for situations where constrained nodes are involved.
This does not mean, however, that the other node also needs to be constrained, or that we can’t have cloud-side infrastructure that processes CoAP interchanges.
Converting to HTTP is certainly an option, but why convert if the other node speaks CoAP, too.

Grüße, Carsten

> On 10 Nov 2014, at 11:32, Turner, Randy <[email-masked]> wrote:
> 
> 
> Hi Carsten,
>

---

From: Simon Lemay <[email-masked]>
Date: Mon, 10 Nov 2014 16:06:40 -1000

Hi Carsten,

In the case of CoAP over TCP, i do like the approach of a simple fixed length header for a few reason,

- it keep coap "as is", meaning that there is no need to have different de/serializer then those who already exists.  And since CoAP makes an effort to have both client and server use the same serialization process, it would be to carry that when implementing on other transport layer.
- if TCP is chosen, we can assume that payload size is not the main concern, hence keeping unused field probably won’t cause problems
- Also, as mentioned in https://tools.ietf.org/html/draft-bormann-core-coap-tcp-01 <https://tools.ietf.org/html/draft-bormann-core-coap-tcp-01> section 3.5, i would agree that is is a likely scenario, and keeping the CoAP structure as is will help with silent behavioral device, or device in low latency area who might not want to keep a connection alive for long periods of time or have intermittent connection.
-it would also help to abstract the under layer and help a more dynamic switching of the transport layer

In the case of 2 or 4 byte long, i do agree that 2 byte might be sufficient but and 4 byte would help avoid second degree fragmentation on bigger message (most likely from not so constraint device, attach to a power source).  I am undecided as to would be the best option.

Thanks

Simon

> On Nov 10, 2014, at 2:01 PM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Randy,
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Nov 2014 16:52:38 -1000

> - if TCP is chosen, we can assume that payload size is not the main concern, hence keeping unused field probably won’t cause problems

As I said in the previous message (http://www.ietf.org/mail-archive/web/core/current/msg05748.html), the number of bytes consumed by the fields is not the only consideration, but in particularly the question whether they continue to carry their UDP semantics or not.

If you want to go for the resilient variant (https://tools.ietf.org/html/draft-bormann-core-coap-tcp-01#section-3.5), that changes everything, of course.  How do you propose to link TCP connections to each other (i.e., how do I know whether a TCP connection I have is good for sending a response to a message that was sent on another TCP connection)?

Grüße, Carsten

---

From: Simon Lemay <[email-masked]>
Date: Tue, 11 Nov 2014 14:22:21 -1000

Hi Carsten, 

Thanks for you reply, these are very good point, 

For the Resilience, this is a good point and would require some more work,  With no security it is feasible with the Endpoint information, but its does get more complicated when adding a security mode.

So aside from that, we could enforce the MessageID and and chosen Message type semantic in all cases (as it is right now for UDP) hence insuring the information is retransmitted.  It would be either that or enforcing to ignore the field without removing them in the case of TCP, the latter one tho creates a switch case base on the transport layer which i believe would be undesirable and would create in my opinion more confusion than it would be helpful.

Simon Lemay

> On Nov 10, 2014, at 4:52 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Nov 2014 14:49:37 -1000

Given that we don’t quite know how to do the resilient case, I think we should focus on the non-resilient case, because that’s what we already use in various environments.

Requiring a TCP generator to generate message layer fields that need to be correct but then need to be studiously ignored by the receiver is an interop accident waiting to happen.

A TCP-UDP bridge already has to run timer management; it is trivial to do the message-ID management within that.

So even a non-multiplexing TCP-UDP bridge does not benefit from the fields being present (and it would need to rely on the TCP generator to fill them in correctly or check them, which is more logic [and more unusual logic] than simply generating them).

The bridge already needs code to discard the length, extending the header back to 4 bytes in order to add in a message-ID doesn’t look like more work.

(This becomes even more straightforward if the length is 2 bytes.)

Grüße, Carsten