Subject: [core] Summary of the CoAP over TCP/TLS Discussions

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Mar 2015 19:05:39 +0100

Hi all,

in preparation for the upcoming IETF meeting I re-read the discussion on
the list (and those exchanged in private). I believe I spotted four main
topics:

1) Interest a new transport for CoAP (based on TCP/TLS)?

Overall, I have seen positive feedback from the group. So far, there was
largely positive feedback on the mailing list and there was also support
at the last IETF meeting. Only one person noted that he only needs the
UDP transport.

This is probably the most important aspect for the group to clarify at
the upcoming meeting and subsequently on the mailing list before moving
forward.

2) The current proposal contained text that lead to some confusion. Here
is the text again:

> "Hence, the only message type supported when using CoAP over TCP
> is the Non-confirmable message (NON)."

While the intention of that sentence was to remove CoAP functionality
that deals with reliability handling it was pointed out that the
Websocket specification describes it better by saying that the message
type is elided (=ignored).

Whatever the final story is, it might make sense to use some time at the
meeting to highlight how CoAP requests and responses interact with the
CoAP message handling in UDP and how things change when we use a
connection-oriented and reliable transport like TCP.

This will ensure that we are all on the same page and can then make an
informed decision.

3) Clarifying the LWM2M specification

As noted on the list the current LWM2M specification does not include
support for a TCP-based transport and requires an update. There also
seems to be additional need to simplify other parts in the specification
that also help to clarify the issue raised in item #2.

Various IETF CORE WG participants are active in the OMA and could help
to improve the readability of the specification in this regard.

4) CoAP over Websockets

The suggestion was made to merge the CoAP over TCP/TLS document with the
CoAP over Websockets due to the similarity of the two specifications.

Most likely the path to get there would be to
a) find out whether there is interest in the CoAP over Websockets work,
b) determine what the document merger implies, and
c) get the authors of the two documents to work together.

I would suggest to discuss topics #1, #2, and #4 at the upcoming IETF
CORE WG meeting.

Ciao
Hannes

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Mon, 16 Mar 2015 12:11:57 +0000

Hannes,

Nice summary. Unfortunately I cannot be at the IETF as the meeting conflicts with another meeting that week and I had to make a priority call before this issue came up.

I would only suggest that in your #2
Whatever the final story is, it might make sense to use some time at the meeting to highlight how CoAP requests and responses interact with the CoAP message handling in UDP and how things change when we use a connection-oriented and reliable transport like TCP.

>> That you look at the client application interaction as applications request the type of request...

BR,
Tim

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, March 15, 2015 1:06 PM
To: [email-masked] WG
Subject: [core] Summary of the CoAP over TCP/TLS Discussions

Hi all,

in preparation for the upcoming IETF meeting I re-read the discussion on the list (and those exchanged in private). I believe I spotted four main
topics:

Overall, I have seen positive feedback from the group. So far, there was largely positive feedback on the mailing list and there was also support at the last IETF meeting. Only one person noted that he only needs the UDP transport.

This is probably the most important aspect for the group to clarify at the upcoming meeting and subsequently on the mailing list before moving forward.

2) The current proposal contained text that lead to some confusion. Here is the text again:

> "Hence, the only message type supported when using CoAP over TCP is 
> the Non-confirmable message (NON)."

While the intention of that sentence was to remove CoAP functionality that deals with reliability handling it was pointed out that the Websocket specification describes it better by saying that the message type is elided (=ignored).

Whatever the final story is, it might make sense to use some time at the meeting to highlight how CoAP requests and responses interact with the CoAP message handling in UDP and how things change when we use a connection-oriented and reliable transport like TCP.

This will ensure that we are all on the same page and can then make an informed decision.

As noted on the list the current LWM2M specification does not include support for a TCP-based transport and requires an update. There also seems to be additional need to simplify other parts in the specification that also help to clarify the issue raised in item #2.

Various IETF CORE WG participants are active in the OMA and could help to improve the readability of the specification in this regard.

4) CoAP over Websockets

The suggestion was made to merge the CoAP over TCP/TLS document with the CoAP over Websockets due to the similarity of the two specifications.

I would suggest to discuss topics #1, #2, and #4 at the upcoming IETF CORE WG meeting.

Ciao
Hannes

---

From: Bill Silverajan <[email-masked]>
Date: Mon, 16 Mar 2015 14:44:22 +0200

Hi Hannes,

> This will ensure that we are all on the same page and can then make an

Please have a look at Section 5 of 
draft-silverajan-core-coap-alternative-transports-07, particularly 
Properties 4, 8 and 10, which pertain to TCP.

One of the goals of the draft is to ensure precisely what you mention 
about being on the same page to capture pertinent decisions when 
designing CoAP over alternative transports, and aims to be a reference 
point for implementers.

> I would suggest to discuss topics #1, #2, and #4 at the upcoming IETF

Seconded.. I'd be at the IETF meeting to discuss the #1, #2 and #4, (and 
also #3 if there's traction next week) but my other two co-authors for 
CoAP over WebSockets won't be physically present.

Regards,
Bill

> Ciao
> Hannes
>
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

-- 
| Bilhanan Silverajan                       Tel: +358 (0)40 849 0757  |
| Tampere University of Technology, Finland                           |

---

From: Simon Lemay <[email-masked]>
Date: Mon, 16 Mar 2015 21:29:21 +0000

Hi all,

Thanks Hannes for this resume,  I would like to add a #5, TCP length
prediction strategy.  The current draft as a fixed 2 byte header and i
strongly believe that leaving it fix a 2 byte would not be enough.  I after
talking to many people, i have collected all the suggested length
prediction strategy.

a) 2 byte fixed length header
b) 4 byte fixed length header
c) Cbor style length (for a lack of better term)
d) 2 byte fixed length header with with trigger to open a different transaction
sematic (to be explored)

When using TCP as a transport layer, the "not so constrained" device can
easily top the FFFF max length (firmware transfer is a easy use case).

I think it would be good to review these and see what fits best.

Cheers

Simon

---

From: "weigengyu" <[email-masked]>
Date: Tue, 17 Mar 2015 09:48:51 +0800

Hi Hannes,

Good summary.

But two things need clarified.

1. In which network to consider CoAP over TCP?
    In RFC7252 it is the Constrained Networks to use CoAP/DTLS/UDP or CoAP 
over UDP.

2. In which network to consider CoAP over WEB Socket?
    In the Constained Networks, or the Internet.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications

---

From: Matthieu Vial <[email-masked]>
Date: Wed, 18 Mar 2015 14:28:30 +0100

Hannes,

I would like to make sure we address the issue raised by Carsten.

"There is one crinkle in the current draft that I think does need to be
discussed:  Some implementations are interpreting the ACK for a
confirmable Observe notification as an application layer signal that
they can free buffers at the server that is implementing Observe
notifications.  We don't have a good way to do this trick with the TCP
binding; if we think that interpretation is a feature, we may have to
cook up something.  I dpn't believe this single function is sufficient
reason to require full message layer semantics on everything transported
over TCP, though."

In LWM2M/CoAP, what are the other options to provide signaling at
application layer for observe notifications ?

Thanks,
Matthieu

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Mar 2015 15:27:49 +0100

Hi Gengyu,

let me respond to your first question:

On 03/17/2015 02:48 AM, weigengyu wrote:
>    In RFC7252 it is the Constrained Networks to use CoAP/DTLS/UDP or
> CoAP over UDP.

We noticed the need for the TCP/TLS transport in enterprise networks
where network administrators block UDP traffic.

It is actually not surprising that this problem surfaces since this was
already an issue when VoIP protocols were developed many, many years ago.

Ciao
Hannes

---

From: "weigengyu" <[email-masked]>
Date: Wed, 18 Mar 2015 23:26:37 +0800

Hi  Hannes,

I make my question clear.

Do you want to do CoAP over TCP in the constrained networks,
or do you want to do CoAP over TCP in the Internet?

It is well known that In RFC7252 CoAP over UDP is default.

If CoAP over TCP is considered in the constrained networks, a reasonable 
story is needed except of TCP popularity.
In this situation optimization of CoAP message layer needs concerning.

Probably, as communications between ISP's server and client device across 
the Internet and the constrained networks,
CoAP over TCP is considered in the Internet.
In this situation optimization of CoAP message layer may not be critical.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Hannes Tschofenig
Sent: Wednesday, March 18, 2015 10:27 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Summary of the CoAP over TCP/TLS Discussions