Subject: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 11 Mar 2015 18:05:18 +0000

Hannes,

I was reading the TCP binding for CoAP (draft-tschofenig-core-coap-tcp-tls-02). First I would like to say that ALU supports a TCP binding for CoAP. However in reading your draft specification there is a critical flaw with the draft and the direction it is taking. That of lack of full support for the CoAP messages.

I can say that OMA LWM2M and oneM2M Protocols rely heavily on the Confirmable, ACK and RST messages within CoAP. Also a seamless integration with the CoAP blockwise transfer specification is necessary. (I haven't evaluated the blockwise yet).

I would hope that any new transport binding for CoAP would continue to support these CoAP messages since we would not want to change implementations in the field because of new transport binding. The LWM2M Server and/or oneM2M CSE application behavior shouldn't change just because we switched out transport protocols. Remember in many cases we will have CSEs and LWM2M Servers (CoAP clients) that will support multiple bindings - for that matter I guess some CoAP Servers might want to support multiple bindings.

>From the OMA LWM2M specification (OMA-TS-LightweightM2M-V1_0-20141111-D):

Transport Layer Binding and Encodings
The LWM2M interfaces use the IETF Constrained Application Protocol [CoAP] as an underlying transfer protocol across IP and SMS bearers. This protocol defines the message header, request/response codes, message options and retransmission mechanisms. This section defines the subset of features from the IETF CoAP specification to be used by LWM2M interfaces.
8.1             Required Features
For realization of the LWM2M interfaces, only the basic binary CoAP message header, and a small subset of options are required. This section explicitly defines the features of the CoAP standard that are required for LWM2M.

*         The 4-byte binary CoAP message header is defined in Section 3 of [CoAP]. This same base message is used for Request and Response interactions.

  *   Confirmable, Acknowledgement and Reset messages MUST be supported. The Reset message is used as a message layer error message in response to a malformed Confirmable message. Non-Confirmable messages MAY be used by a Client for sending Information Reporting notifications as per [Observe].
  *   GET, PUT, POST and DELETE methods MUST be supported. LWM2M Operations map to these methods.
  *   A subset of Response Codes MUST be supported for LWM2M response message mapping.
  *   The Uri-Path Option MUST be supported to indicate the identifier of the interface, Object Instance and Resource being requested.
  *   The Location-Path Option MUST be supported to indicate the handle of a registration for future update and delete operations.
  *   The Uri-Query Option MUST be supported.
  *   The Content-Type Option MAY be used to indicate the media type of the payload. A default value of plain/text is assumed, allowing this option to be elided for most payloads.
  *   The Token Option MAY be used to enable multiple requests in parallel with an endpoint, and MUST be supported for the Information Reporting interface.

>From oneM2M Protocol binding (TS-0008v1.0.1)
5                 Overview
The clause describes which features need to be supported in CoAP layer and introduces a message format and several features of CoAP used in this procotol binding specification.
5.1              Required Features
This clause explicitely specifies the required features of the CoAP layer for oneM2M to propery bind oneM2M primitives into CoAP messages.

*            The 4-byte binary CoAP message header is defined in Section 3 of [1].

*            Confirmable (CON), Acknowledgement (ACK) and Reset (RST) messages shall be supported. The Reset message is used to send a error message in response to a malformed Confirmable message in CoAP layer.

*            GET, PUT, POST and DELETE methods shall be supported. oneM2M primitives map to these methods.

*            A subset of Response Code specified in clause 6.2.4 shall be supported for oneM2M Response Status Code parameter mapping.

*            The Uri-Host, Uri-Port, Uri-Path, and Uri-Query shall be supported.

*            The Content-Type Option shall be used to indicate the media types of the payload.

*            The Token Option may be used.

*            Block-wise transfers feature may be supported to carry large payloads.

*            Caching feature may be supported.

BR,
Tim

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Mar 2015 23:47:59 +0100

Hi Tim,

> lack of full support for the CoAP messages.

The TCP/TLS binding is indeed proposing to perform the functions of the
CoAP message layer with the reliability features that TCP and TLS
already provide.

> I can say that OMA LWM2M and oneM2M Protocols rely heavily on the
> Confirmable, ACK and RST messages within CoAP. 

They do because there is no other way to obtain reliability with UDP.
With TCP, the message layer ACK function (not the actual response
possibly piggybacked in one) is redundant.

In a request/response protocol, the application layer feedback that a
request was processed is not provided by the ACK, but by the response.
That is forwarded unchanged.

> Also a seamless
> integration with the CoAP blockwise transfer specification is necessary.

I certainly agree with that observation; I believe we have that covered
in the current text.

> I would hope that any new transport binding for CoAP would continue to
> support these CoAP messages since we would not want to change
> implementations in the field because of new transport binding. 

If you implement a new transport, you need to change the implementation.
Maybe I don't understand what you are trying to say.

Can you provide an example how implementations would be impacted?

>   * *Confirmable, Acknowledgement and Reset messages MUST be supported.

Well, of course: they are needed for UDP.

>     The Reset message is used as a message layer error message in
>     response to a malformed Confirmable message. 

Right.  So, indeed, the handling of malformed messages requires some
additional text in the transport binding; that is currently missing.

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.

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Wed, 11 Mar 2015 23:05:28 +0000

Carsten,

The point I was trying to make is that the LWM2M application(s) interface to the CoAP layer cannot change. The LWM2M and oneM2M endpoints rely on the ACK, RST Messages from the CoAP Layer. If the CoAP layer doesn't provide these messages  to the LWM2M or oneM2M endpoints when bound using TCP then the LWM2M or oneM2M endpoints will have to change their code - we do not want that just because we have there is  different transport binding.

Even if we have a "transparent" confirmation mechanism through CoAP we still need those messages. Just pointing out how the industry is using the protocol.

BR,
Tim
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2015 5:48 PM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Hi Tim,

> lack of full support for the CoAP messages.

The TCP/TLS binding is indeed proposing to perform the functions of the CoAP message layer with the reliability features that TCP and TLS already provide.

They do because there is no other way to obtain reliability with UDP.
With TCP, the message layer ACK function (not the actual response possibly piggybacked in one) is redundant.

In a request/response protocol, the application layer feedback that a request was processed is not provided by the ACK, but by the response.
That is forwarded unchanged.

> integration with the CoAP blockwise transfer specification is necessary.

I certainly agree with that observation; I believe we have that covered in the current text.

>     response to a malformed Confirmable message. 

Right.  So, indeed, the handling of malformed messages requires some additional text in the transport binding; that is currently missing.

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.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 12 Mar 2015 00:37:38 +0000

Having implemented LWM2M, I do not see where an implementation would need to rely on ACKs or RSTs (or CONs other than being able to send reliable messages).

Ciao
Matthias

> From: core [mailto:[email-masked]] On Behalf Of Carey, Timothy
> (Timothy)
> Sent: Donnerstag, 12. März 2015 00:05
> To: Carsten Bormann
> Cc: [email-masked]
> The point I was trying to make is that the LWM2M application(s) interface to
> the CoAP layer cannot change. The LWM2M and oneM2M endpoints rely on
> the ACK, RST Messages from the CoAP Layer. If the CoAP layer doesn't
> provide these messages  to the LWM2M or oneM2M endpoints when bound
> using TCP then the LWM2M or oneM2M endpoints will have to change their
> code - we do not want that just because we have there is  different transport
> binding.
> 
> Even if we have a "transparent" confirmation mechanism through CoAP we
> still need those messages. Just pointing out how the industry is using the
> protocol.
> 
> BR,
> Tim
> CoAP message layer with the reliability features that TCP and TLS already
> provide.
> 
> In a request/response protocol, the application layer feedback that a request
> was processed is not provided by the ACK, but by the response.
> 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.
> 
> Grüße, Carsten
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 12 Mar 2015 03:54:31 +0000

Matthias,

LWM2M Specification uses CoAP ACK for the LWM2M server's Queue mode (section 8.3). Likewise RST is used as a message layer error message in response to a malformed Confirmable message. 

oneM2M uses similar mappings for Confirmable messages in its CoAP binding primitives for various message exchange patterns (e.g., non-blocking asynchronous requests, non-blocking synchronous, blocking) supported by the oneM2M protocol. In fact the specification for the CoAP binding doesn't even use the NON message.

The point is that these standards rely on Confirmable (CON) messages which the draft explicitly states it doesn't support.
"Hence, the only message type supported when using CoAP over TCP is
the Non-confirmable message (NON)."

This is the first problem we need Confirmable (CON) message types.
The second problem is that in the use of the Confirmable messages the specifications use the ACK and RST messages for various purposes in those specifications.

So in your implementation you do not set the message type to CON when you send a reliable message?
I have seen implementations that actually checked to make sure the message type was CON and error otherwise.

So now we introduce TCP and I have to have something like
If message-exchange-pattern == reliable then
If UDP transport then sendMessage(CON)
elseIf TCP transport then sendMessage(NON)

With all that implies in the response processing as well.

I really don't want to have to interrogate the Transport binding of the Socket to determine the message type for a specific message pattern. The shim layer of the transport should take care of handling all the CoAP messages - if the specification allows for that - we will have less interop problems IMHO.

BR,
Tim

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2015 7:38 PM
To: Carey, Timothy (Timothy); Carsten Bormann
Cc: [email-masked]
Subject: RE: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Ciao
Matthias

> The point I was trying to make is that the LWM2M application(s) 
> interface to the CoAP layer cannot change. The LWM2M and oneM2M 
> endpoints rely on the ACK, RST Messages from the CoAP Layer. If the 
> CoAP layer doesn't provide these messages  to the LWM2M or oneM2M 
> endpoints when bound using TCP then the LWM2M or oneM2M endpoints will 
> have to change their code - we do not want that just because we have 
> there is  different transport binding.
> 
> still need those messages. Just pointing out how the industry is using 
> the protocol.
> 
> BR,
> Tim
> The TCP/TLS binding is indeed proposing to perform the functions of 
> the CoAP message layer with the reliability features that TCP and TLS 
> already provide.
> 
> > I would hope that any new transport binding for CoAP would continue 
> > to support these CoAP messages since we would not want to change 
> reason to require full message layer semantics on everything transported over TCP, though.
> 
> Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 12 Mar 2015 07:33:02 +0000

Dear Tim

> LWM2M Specification uses CoAP ACK for the LWM2M server's Queue mode
> (section 8.3).

The Queue Mode uses the ACK_TIMEOUT to decide whether the server has queued messages. With CoAP-over-TCP, the Client would decide that on whether or not the LWM2M Server closes the TCP connection or not.

The note "Each request is sent serially to the LWM2M Client, waiting for request to be Acknowledged before sending the next request" from the LWM2M TS does not apply either, as TCP is reliable and guarantees message order.

> Likewise RST is used as a message layer error message in

Basically the same here: The appropriate response to malformed CoAP requests would be closing the TCP connection.

> The point is that these standards rely on Confirmable (CON) messages which
> the draft explicitly states it doesn't support.

Because every message becomes reliable over a reliable transport.

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

I agree that this is a bug in the draft or rather a misleading statement. I am not sure why the Type is actually back(?) in there.

> I have seen implementations that actually checked to make sure the
> message type was CON and error otherwise.

I do use CONs because I use CoAP (over UDP). However, I do not expose the ACKs to LWM2M, only requests and response. An exception is the RST for Observe: I use it to cancel observe relationships in addition to the proper GET with Observe=1. This can be considered an optimization. (However, it is important to point out that in CoAP-over-TCP, endpoints must not do the equivalent of sending a RST message when receiving an unknown notification, that is, closing the TCP connection. Not sure what the status is here...)

> So now we introduce TCP and I have to have something like If message-
> exchange-pattern == reliable then If UDP transport then sendMessage(CON)

No. The LWM2M logic should always only deal with requests and responses. Everything else is a bug in the TS.

Best regards
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Mar 2015 08:43:37 +0100

Kovatsch Matthias wrote:
>  (However, it is important to point out that in CoAP-over-TCP, endpoints must not do the equivalent of sending a RST message when receiving an unknown notification, that is, closing the TCP connection. Not sure what the status is here...)

What is the sequence of events leading up to such an unknown
notification?  (I assume this is a short form of saying "response with a
token that is not in use"?)

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 12 Mar 2015 08:07:15 +0000

> Kovatsch Matthias wrote:
> >  (However, it is important to point out that in CoAP-over-TCP,
> > endpoints must not do the equivalent of sending a RST message when
> > receiving an unknown notification, that is, closing the TCP
> > connection. Not sure what the status is here...)
> 
> What is the sequence of events leading up to such an unknown notification?
> (I assume this is a short form of saying "response with a token that is not in
> use"?)

Indeed. I have not put much thought into possible reasons other than crash/reboot from the UDP case. When using TCP, a reboot will terminate the connection anyway. So what remains is a partial crash while processing a cancellation, for instance. I guess in such a case closing the connection (and hence terminating all other open requests) might actually be a valid reaction. Are there any thoughts on this in the "TCP task force"?

Ciao
Matthias

---

From: Julien Vermillard <[email-masked]>
Date: Thu, 12 Mar 2015 08:10:53 +0000

Hi,
When using TCP closing the connection for flushing and bad state (protocol
parser or any state machine) is usually a good idea.
So I suppose if we receive a malformed packet, like one with an unknown
token/MID, we can just close the connection and try to connect/register
again.
Julien

On Thu, Mar 12, 2015 at 9:07 AM Kovatsch Matthias <[email-masked]>
wrote:

> notification?
> Indeed. I have not put much thought into possible reasons other than
> crash/reboot from the UDP case. When using TCP, a reboot will terminate the
> connection anyway. So what remains is a partial crash while processing a
> cancellation, for instance. I guess in such a case closing the connection
> (and hence terminating all other open requests) might actually be a valid
> reaction. Are there any thoughts on this in the "TCP task force"?
>
> Ciao
> Matthias
>

---

From: Zach Shelby <[email-masked]>
Date: Thu, 12 Mar 2015 01:08:10 -0700

Tim,

I agree with Matthias here, the actual implementation dependency of LWM2M should purely be with the Request and Response semantics of CoAP.

There are clearly are some badly written sentences in the LWM2M specification, such as requiring the support of CON, ACK and RST. Since I wrote those sentences, happy to take the blame, and also correct them in a future update. As a defence, the original CoAP text in the LWM2M specification was written with a very detailed description about what parts of CoAP need to be implemented, because several parties involved were worried about the "complexity" of implementing CoAP. Since that is no longer an issue, the text can be greatly improved.

In order to add TCP as a binding for LWM2M, a specification update is needed anyways, and in that same update we can absolutely fix text which confuses the internals of CoAP's messaging layer regard UDP vs. TCP. We can also fix things like the use of timeouts in an agnostic way, regardless of the binding. The SMS binding already has similar issues.

In conclusion, let's fix the LWM2M specifications where it is badly written, rather than building a convoluted TCP binding for CoAP.

Zach

> No. The LWM2M logic should always only deal with requests and responses. Everything else is a bug in the TS.

Zach Shelby
Vice President, Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Mar 2015 09:28:58 +0100

> Indeed. I have not put much thought into possible reasons other than crash/reboot from the UDP case. When using TCP, a reboot will terminate the connection anyway. So what remains is a partial cras…

Since a TCP connection is not that expensive, using it as the container
of coherent state sounds like the right thing to do.  So if you actually
do lose some state (I'm still having a bit trouble visualizing how that
could be partial), you start a new TCP connection.

Grüße, Carsten

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Thu, 12 Mar 2015 13:25:19 +0000

Zach,

I am not worried about updating specifications to be honest - its only paper...;-) Actually that isn't entirely true because we have to think about the backward compatibility of the Application code implementations which aren't paper.

>From the Application point of view the message layer is indeed part of Request and Response semantics of CoAP. The CoAP specification asks the Application to choose the variation of the Request and Response message exchange pattern - confirmable or non-confirmable messaging. That makes it part of the Request and Response semantics.

Why would we ask an Application to choose the message exchange pattern variation if the transport is UDP but not if it is another transport or worse yet, in the case of the TCP draft, deny the use of the pattern? 

The Application behavior to sending and receiving CoAP messages should be the same regardless of the underlying transport - that isn't the direction we are taking with the TCP draft.

BR,
Tim

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]] 
Sent: Thursday, March 12, 2015 3:08 AM
To: Kovatsch Matthias
Cc: Carey, Timothy (Timothy); Carsten Bormann; [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Tim,

Zach

On Mar 12, 2015, at 9:33 AM, Kovatsch Matthias <[email-masked]> wrote:

>> Likewise RST is used as a message layer error message in response to 
>> a malformed Confirmable message.
>
>> The point is that these standards rely on Confirmable (CON) messages 
>> which the draft explicitly states it doesn't support.
>
> I do use CONs because I use CoAP (over UDP). However, I do not expose 
> the ACKs to LWM2M, only requests and response. An exception is the RST 
> for Observe: I use it to cancel observe relationships in addition to 
> the proper GET with Observe=1. This can be considered an optimization. 
>> exchange-pattern == reliable then If UDP transport then 
>> sendMessage(CON) elseIf TCP transport then sendMessage(NON)
>

Zach Shelby

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: "weigengyu" <[email-masked]>
Date: Fri, 13 Mar 2015 08:23:48 +0800

Hi Julien, 

Can you clarify what the malformed packet means in the following sentence?
> So I suppose if we receive a malformed packet, like one with an unknown token/MID, we can just close the connection and try to connect/register again.

Is it a CoAP message, or a TCP segment, or an IP packet?
It is likely to be a CoAP message, is it?

If the CoAP message is wrong, it may not fix by doing “just close the connection and try to connect/register again” .

Regards, 

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

From: Julien Vermillard 
Sent: Thursday, March 12, 2015 4:10 PM
To: Kovatsch Matthias ; Carsten Bormann 
Cc: Carey, Timothy (Timothy) ; [email-masked] 
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Hi,
When using TCP closing the connection for flushing and bad state (protocol parser or any state machine) is usually a good idea 
So I suppose if we receive a malformed packet, like one with an unknown token/MID, we can just close the connection and try to connect/register again.
Julien

  Ciao
  Matthias

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

---

From: "weigengyu" <[email-masked]>
Date: Fri, 13 Mar 2015 16:01:24 +0800

Hi Tim，

〉The Application behavior to sending and receiving CoAP messages should be 
the same regardless of the underlying transport

No.
Why there are two sublayers defined within CoAP? it is because CoAP is on 
top of UDP as default.

Considering CoAP over TCP, most functions of the message layer is not 
required in terms of reliability.
If the message layer is existed without any changes, it would bring some 
function redundences and processing overhead for the protocol stack.

The overhead may increases processing latency and power costs.
But, I think that the protocol validity is not effected.

Best Regards,

Gengyu WEI
-----原始邮件----- 
From: Carey, Timothy (Timothy)
Sent: Thursday, March 12, 2015 9:25 PM
To: Zach Shelby ; Kovatsch Matthias
Cc: [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Zach,

I am not worried about updating specifications to be honest - its only 
paper...;-) Actually that isn't entirely true because we have to think about 
the backward compatibility of the Application code implementations which 
aren't paper.

>From the Application point of view the message layer is indeed part of 
>Request and Response semantics of CoAP. The CoAP specification asks the 
>Application to choose the variation of the Request and Response message 
>exchange pattern - confirmable or non-confirmable messaging. That makes it 
>part of the Request and Response semantics.

Why would we ask an Application to choose the message exchange pattern 
variation if the transport is UDP but not if it is another transport or 
worse yet, in the case of the TCP draft, deny the use of the pattern?

The Application behavior to sending and receiving CoAP messages should be 
the same regardless of the underlying transport - that isn't the direction 
we are taking with the TCP draft.

BR,
Tim

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 3:08 AM
To: Kovatsch Matthias
Cc: Carey, Timothy (Timothy); Carsten Bormann; [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Tim,

I agree with Matthias here, the actual implementation dependency of LWM2M 
should purely be with the Request and Response semantics of CoAP.

There are clearly are some badly written sentences in the LWM2M 
specification, such as requiring the support of CON, ACK and RST. Since I 
wrote those sentences, happy to take the blame, and also correct them in a 
future update. As a defence, the original CoAP text in the LWM2M 
specification was written with a very detailed description about what parts 
of CoAP need to be implemented, because several parties involved were 
worried about the "complexity" of implementing CoAP. Since that is no longer 
an issue, the text can be greatly improved.

In order to add TCP as a binding for LWM2M, a specification update is needed 
anyways, and in that same update we can absolutely fix text which confuses 
the internals of CoAP's messaging layer regard UDP vs. TCP. We can also fix 
things like the use of timeouts in an agnostic way, regardless of the 
binding. The SMS binding already has similar issues.

In conclusion, let's fix the LWM2M specifications where it is badly written, 
rather than building a convoluted TCP binding for CoAP.

Zach

On Mar 12, 2015, at 9:33 AM, Kovatsch Matthias <[email-masked]> wrote:

> The Queue Mode uses the ACK_TIMEOUT to decide whether the server has 
> queued messages. With CoAP-over-TCP, the Client would decide that on 
> whether or not the LWM2M Server closes the TCP connection or not.
>
> The note "Each request is sent serially to the LWM2M Client, waiting for 
> request to be Acknowledged before sending the next request" from the LWM2M 
> TS does not apply either, as TCP is reliable and guarantees message order.
>
> Basically the same here: The appropriate response to malformed CoAP 
> requests would be closing the TCP connection.
>
> I agree that this is a bug in the draft or rather a misleading statement. 
> I am not sure why the Type is actually back(?) in there.
>

Zach Shelby

-- 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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2557590 ARM Holdings plc, 
Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in 
England & Wales, Company No:  2548782

---

From: Julien Vermillard <[email-masked]>
Date: Fri, 13 Mar 2015 08:19:37 +0000

Hi,
I mean at the protocol level, here CoAP messages.
TCP level have already it own way to handle this problem.
Julien

On Fri, Mar 13, 2015 at 1:25 AM weigengyu <[email-masked]> wrote:

> If the CoAP message is wrong, it may not fix by doing “just close the
> connection and try to connect/register again” .
>
> Regards,
>
> Gengyu WEI
>  *From:* Julien Vermillard <[email-masked]>
> *Sent:* Thursday, March 12, 2015 4:10 PM
> *To:* Kovatsch Matthias <[email-masked]> ; Carsten Bormann
> <[email-masked]>
> *Cc:* Carey, Timothy (Timothy) <[email-masked]> ;
> [email-masked]
> *Subject:* Re: [core] Message support in
> draft-tschofenig-core-coap-tcp-tls-02
> Hi,
> parser or any state machine) is usually a good idea

---

From: "Timothy L. Hirou" <[email-masked]>
Date: Fri, 13 Mar 2015 08:39:50 +0000

I have kept silent for along time. For our applications (large systems requiring the lowest latency possible) UDP is the only choice.

There comes a point where taking the "One Size Fits All Approach"‎ is not the wisest path, technologically. Having said that, I know that this is not economically popular.

That said, I have heard all the rhetoric that the IETF has worked hard to get rid of all the "cruff", (e.g. I read this as a visibility to the edge issue), but when ideology starts to take precedence over the best technological choices to make in standards development, for the sanctity of pure technology intellectual thought and technology development, someone needs to call a "Spade a Spade".

Our approach is "Suitability to Task", when it comes to choosing the proper technological approach. At some point the "home market solution set" and the "commercial/industrial market set" needs to be split. Is this now the time?

Best Regards,

Timothy L. Hirou
President & CEO
Convergence Wireless, Inc.
3334 E. Coast Highway
Corona Del Mar, CA 92625
(800) 519-9820 Office
(949) 444-1723 Cell
(949) 258-5592 Fax
[email-masked]
www.convergencewireless.com

Privileged And Confidential Communication This electronic transmission, and any documents attached hereto, (a) are protected by the Electronic Communications
privacy Act (18 USC §§ 2510- 2521),(b)may contain confidential and or legally privileged information , and (c) are
for the sole use of the intended recipient(s) named above.  If you have received this electronic message in error, please notify the sender and delete the electronic message and destroy any physical copies of the information that
may have been generated. Any disclosure, copying, distribution, or use of the contents of the information received in
error is strictly prohibited.

  Original Message
From: weigengyu
Sent: Friday, March 13, 2015 1:01 AM
To: Carey, Timothy (Timothy)
Cc: [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Hi Tim，

No.

Best Regards,

Gengyu WEI
-----原始邮件-----
From: Carey, Timothy (Timothy)
Sent: Thursday, March 12, 2015 9:25 PM
To: Zach Shelby ; Kovatsch Matthias
Cc: [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Zach,

BR,
Tim

-----Original Message-----
From: Zach Shelby [mailto:[email-masked]]
Sent: Thursday, March 12, 2015 3:08 AM
To: Kovatsch Matthias
Cc: Carey, Timothy (Timothy); Carsten Bormann; [email-masked]
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Tim,

Zach

Zach Shelby

---

From: Matthieu Vial <[email-masked]>
Date: Fri, 13 Mar 2015 12:00:39 +0100

Zach,

As Carsten already mentionned, we still need CON/ACK for reliable
notifications.
In our TCP implementation, this is the only place where TCP is not enough.

Matthieu

On Thu, Mar 12, 2015 at 9:08 AM, Zach Shelby <[email-masked]> wrote:

> worried about the "complexity" of implementing CoAP. Since that is no
> longer an issue, the text can be greatly improved.
>
> In order to add TCP as a binding for LWM2M, a specification update is
> needed anyways, and in that same update we can absolutely fix text which
> confuses the internals of CoAP's messaging layer regard UDP vs. TCP. We can
> also fix things like the use of timeouts in an agnostic way, regardless of
> the binding. The SMS binding already has similar issues.
>
> In conclusion, let's fix the LWM2M specifications where it is badly
> written, rather than building a convoluted TCP binding for CoAP.
>
> Zach
>
> which
> > I agree that this is a bug in the draft or rather a misleading
> statement. I am not sure why the Type is actually back(?) in there.
> >
> the ACKs to LWM2M, only requests and response. An exception is the RST for
> Observe: I use it to cancel observe relationships in addition to the proper
> GET with Observe=1. This can be considered an optimization. (However, it is
> important to point out that in CoAP-over-TCP, endpoints must not do the
> equivalent of sending a RST message when receiving an unknown notification,
> that is, closing the TCP connection. Not sure what the status is here...)
> >
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
>

---

From: "Carey, Timothy (Timothy)" <[email-masked]>
Date: Fri, 13 Mar 2015 14:32:39 +0000

Matthias,

Thanks for the reply – that was a great help to me.

> I agree that this is a bug in the draft or rather a misleading statement. I am not sure why the Type is actually back(?) in there.

If indeed we believe as Zach and you have indicated that the client applications (e.g., LWM2M) shouldn’t reference the elements of the message layer with the exception of indicating which type of message (NON, CON) and the respective specifications can be clarified to remove these dependencies - I think we can work with that.

Zach – what do you think? In the TCP draft – you can simply say that the message type and message id is elided. The Websocket draft takes a similar approach as I read it in section 2.2. Maybe even use their wording?

BR,
Tim

From: Matthieu Vial [mailto:[email-masked]]
Sent: Friday, March 13, 2015 6:01 AM
Cc: Kovatsch Matthias; Carey, Timothy (Timothy); [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Message support in draft-tschofenig-core-coap-tcp-tls-02

Zach,
As Carsten already mentionned, we still need CON/ACK for reliable notifications.
In our TCP implementation, this is the only place where TCP is not enough.

Matthieu

On Thu, Mar 12, 2015 at 9:08 AM, Zach Shelby <[email-masked]<mailto:[email-masked]>> wrote:
Tim,

Zach

On Mar 12, 2015, at 9:33 AM, Kovatsch Matthias <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>
Zach Shelby
Vice President, Marketing
ARM Internet of Things BU
www.arm.com<http://www.arm.com>
US: +1 (408) 203-9434<tel:%2B1%20%28408%29%20203-9434>
Finland: +358 407796297<tel:%2B358%20407796297>
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/<http://fi.linkedin.com/in/zachshelby/>

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Mar 2015 15:44:41 +0100

Carey, Timothy (Timothy) wrote:
> Zach – what do you think? In the TCP draft – you can simply say that the
> message type and message id is elided. The Websocket draft takes a
> similar approach as I read it in section 2.2. Maybe even use their wording?
> 

One thing that we discussed offline was whether we shouldn't just merge
the TCP and websockets drafts.
While the interest in the specific solution for websockets appears to be
lower than that for TCP and TLS, 90 % of the content is the same, and
the websockets draft has better explanations for some issues.
(The websocket specific part could be moved to an appendix.)

I would be prepared to do the editorial work of merging them if the
other authors (of the TCP/TLS draft and the websockets draft) agree.

Grüße, Carsten

---

From: Andrew Mcgregor <[email-masked]>
Date: Mon, 16 Mar 2015 09:30:14 +1100

Merging TCP and websockets seems reasonable; that then pretty much covers
any reliable stream transport adequately, at least for a first pass.

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 1071 2221