[core] CoAP + TLS question on signaling

[Jim Schaad]

I am trying to decide where to put the signaling code in my stack and as
part of that question I started to wonder if the signaling messages are
applicable to the UDP and other transport cases as well.

I also wanted to be sure that there was no intention that if a release w/ an
alternative address is sent, there is no intention that any state would be
transferred between to the new connection.

Jim

[Carsten Bormann]

Hi Jim,

Post by Jim Schaad
I am trying to decide where to put the signaling code in my stack and as
part of that question I started to wonder if the signaling messages are
applicable to the UDP and other transport cases as well.

As defined they are not; they are defined for TCP, TLS, ws, wss.

Now is it likely that this will ever change?

For UDP, no. Signaling is about the current connection, and there is no such thing in UDP. The only signaling function that doesn’t really need the connection is PING/PONG, and we have other ways of doing this. (The only new thing here, the custody option, only makes sense for a sequence-preserving reliable connection.)

DTLS does have a connection, but the current signaling messages are not very useful for controlling that. Still not that likely.

Other transports: Could be. Christian Groves' draft for CoAP over WebRTC data channel certainly uses them.

Post by Jim Schaad
I also wanted to be sure that there was no intention that if a release w/ an
alternative address is sent, there is no intention that any state would be
transferred between to the new connection.

Indeed, this option only says how to get a new connection; there is no intention that its state is otherwise influenced.

We should probably say that; opened an issue (#144).

Grüße, Carsten

[Jim Schaad]

See inline.

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Friday, April 28, 2017 10:34 AM
To: Jim Schaad <***@augustcellars.com>
Cc: core <***@ietf.org>
Subject: Re: [core] CoAP + TLS question on signaling

Hi Jim,

Post by Jim Schaad
I am trying to decide where to put the signaling code in my stack and
as part of that question I started to wonder if the signaling messages
are applicable to the UDP and other transport cases as well.

As defined they are not; they are defined for TCP, TLS, ws, wss.

Now is it likely that this will ever change?

For UDP, no. Signaling is about the current connection, and there is no such thing in UDP. The only signaling function that doesn’t really need the connection is PING/PONG, and we have other ways of doing this. (The only new thing here, the custody option, only makes sense for a sequence-preserving reliable connection.)

[JLS] I am unsure that the max message size might not be a useful option to send between items. While this can be detected in other ways, it might still be useful for a client to say that I want something even smaller.

[JLS] I am not sure that I understand why the custody option is based on a sequence-preserving reliable connection. I don't see any reason why 1) I cannot have two active requests on a single reliable connection (separated by the token) and 2) there is any reason to assume that requests will create responses in order. I would expect that some "heavy duty" requests might generate responses out of order thus killing the sequence preservation. Additionally, an ACK followed later by a response should be detected for the custody option.


DTLS does have a connection, but the current signaling messages are not very useful for controlling that. Still not that likely.


Other transports: Could be. Christian Groves' draft for CoAP over WebRTC data channel certainly uses them.

[JLS] Yes, I was actually thinking of SMS at the time.

Jim

Post by Jim Schaad
I also wanted to be sure that there was no intention that if a release
w/ an alternative address is sent, there is no intention that any
state would be transferred between to the new connection.

Indeed, this option only says how to get a new connection; there is no intention that its state is otherwise influenced.

We should probably say that; opened an issue (#144).

Grüße, Carsten

[Carsten Bormann]

Post by Jim Schaad
[JLS] I am unsure that the max message size might not be a useful option to send between items. While this can be detected in other ways, it might still be useful for a client to say that I want something even smaller.

Yes. We would need to put more protocol around that, as it is not quite clear what the capability would be applied to.
Devices occasionally change their addresses, and the address might be re-used by another device that does not implement this message.
So right now I feel more comfortable with 4.13 “Request entity too large” (RFC 7959 Section 2.5); this has the same problems around an undefined validity period, but people are likely to implement this as a hint.

Post by Jim Schaad
[JLS] I am not sure that I understand why the custody option is based on a sequence-preserving reliable connection.

Well, it says “everything you sent before you sent this PING I’m responding to has been processed”.
That statement has a meaning on a sequenced connection, but not with UDP where packets can be reordered.

Post by Jim Schaad
I don't see any reason why 1) I cannot have two active requests on a single reliable connection (separated by the token)

(NSTART considerations notwithstanding).

Post by Jim Schaad
and 2) there is any reason to assume that requests will create responses in order. I would expect that some "heavy duty" requests might generate responses out of order thus killing the sequence preservation. Additionally, an ACK followed later by a response should be detected for the custody option.

I think you are proposing an interpretation of the form “everything I sent you a response for has been processed”.
Wouldn’t that be something you would want to attach to the responses instead of sending it separately?

Grüße, Carsten