Subject: Re: [core] CoAP Endpoint Identification

From: Floris Van den Abeele <[email-masked]>
Date: Mon, 20 Oct 2014 16:58:04 +0200

Apologies for reviving a three week old thread, but it might be
interesting to poll the list on how people are addressing the issue of
servers with changing IP addresses (i.e. mobile servers) today?

I have considered using a proxy for this purpose (so that at least from
the client's POV there is a stable IP address for its server), but the
issue raised in Oliver's draft is obviously still present between the
proxy and server. For the latter, I intended to use a Resource Directory
to signal IP address changes (via the context parameter) and either have
the proxy update its observe 'relationships' or just re-establish all
observe 'relationships' with the server (with some information loss
being a likely possibility, but as this is in-line with the eventual
consistency goal of observe this might be OK for some use-cases).

A simpler work-around (!) could be to use something like a mirror proxy
and omit the problem entirely. By forcing the server to become a client
this doesn't fall under the category of problems addressed by Oliver's,
but it is a fairly straight-forward method for supporting mobile CoAP
endpoints (with the added issue of synchronization between mirror server
and the mobile client).

Any comments from what people on the list have running today?

Floris
On 29-09-14 11:06, Oliver Kleine wrote:
> Hi,
>
> Am 28.09.2014 um 07:12 schrieb weigengyu:
>
>> When Node ID (NID) or Endpoint ID (EID) is defined and every CoAP
>> Endpoint has a unique ID that is never changed.
> the term "never changed" is not exactly true for EIDs. Let me explain
> that. I wanted the EIDs to be independent from any layers or other
> components but the CoAP layer on just both endpoints. Every other layer
> has its identifiers with a certain lifetime, e.g. MAC addresses on the
> network layer, IP addresses on the Internet layer and ports on the
> transport layer. All of them are necessary to transfer data from one
> source process to the other (maybe remote) destination process.
>
> The EID approach follows that well established tradition by defining an
> independent new identifier for the specific purpose of relating requests
> to responses and update notifications just for the necessary lifetime.
>
> In CoAP the mutually assigned EIDs are valid for the duration of one
> conversation. A conversation is considered the the set of all messages
> between two endpoints that share the same token instance, e.g. a single
> request/response pair or one request and an unbound set of update
> notifications.
>
> Best,
> Oliver
>
>
>> -----原始邮件----- From: Olaf Bergmann
>> Sent: Thursday, September 25, 2014 4:34 PM
>> To: Likepeng
>> Cc: [email-masked]
>> Subject: Re: [core] CoAP Endpoint Identification
>>
>> Kepeng,
>>
>> Likepeng <[email-masked]> writes:
>>
>>> Endpoint ID can be used as "Description" parameter in the
>>> authorization request as mentioned in this draft.
>>> http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/
>>>
>>>       D: Description.  A descriptive label of the initiator of the
>>>       authorization request.  This label MAY be a fully qualified domain
>>>       name, an IP address, or any other character literal that is used
>>>       by the Authorization Server to decide whether or not access is
>>>       granted to the requesting entity.
>>>
>>> For this parameter, IP address is not stable, domain name may not be
>>> available. Endpoint ID is a good candidate.
>> This was indeed our general mindset.
>>
>> Gruesse
>> Olaf
>>
>> _______________________________________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/core
>> _______________________________________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 21 Oct 2014 14:08:52 +0000

Hi Floris

I think it is good to revive this thread, since this is still an actual problem and there is no good solution yet, at least no good overall description.

A feasible way is definitely to use the RD announce address changes.
Re-registering observe relationships is also not that expensive, so I would do this instead of a dirty hack that modifies the observe semantics.
If the goal is also to prevent losing notification (Oliver’s problem), draft-koster-core-coapmq is something to look into.

A problem I see with the mirror proxy is that I will not work for actuation, i.e., in the case we want to send commands to a device with changing addresses.

Comments on Oliver’s proposal: As Hannes mentioned, an IP address change will require a new DTLS handshake and message matching is only allowed within the same security context (IIRC). Hence, the client is required to re-register anyway. The 24h you mentioned are for something different; the client can re-register whenever it wants to and the Max-Age is a good hint for the time span to expect a notification. As stated above, message queueing is a much better approach to prevent information loss (although it conflicts with the eventual consistency philosophy of Observe, but it gets the job done for the use cases…).

Ciao
Matthias

From: core [mailto:[email-masked]] On Behalf Of Floris Van den Abeele
Sent: Montag, 20. Oktober 2014 16:58
To: [email-masked]
Subject: Re: [core] CoAP Endpoint Identification

Apologies for reviving a three week old thread, but it might be interesting to poll the list on how people are addressing the issue of servers with changing IP addresses (i.e. mobile servers) today?

I have considered using a proxy for this purpose (so that at least from the client's POV there is a stable IP address for its server), but the issue raised in Oliver's draft is obviously still present between the proxy and server. For the latter, I intended to use a Resource Directory to signal IP address changes (via the context parameter) and either have the proxy update its observe 'relationships' or just re-establish all observe 'relationships' with the server (with some information loss being a likely possibility, but as this is in-line with the eventual consistency goal of observe this might be OK for some use-cases).

A simpler work-around (!) could be to use something like a mirror proxy and omit the problem entirely. By forcing the server to become a client this doesn't fall under the category of problems addressed by Oliver's, but it is a fairly straight-forward method for supporting mobile CoAP endpoints (with the added issue of synchronization between mirror server and the mobile client).

Floris

Hi,

notifications.

Best,

Oliver

To: Likepeng

Cc: [email-masked]<mailto:[email-masked]>

Kepeng,

Likepeng <[email-masked]><mailto:[email-masked]> writes:

Gruesse

Olaf

core mailing list

[email-masked]<mailto:[email-masked]>

core mailing list

[email-masked]<mailto:[email-masked]>

core mailing list

[email-masked]<mailto:[email-masked]>

---

From: Oliver Kleine <[email-masked]>
Date: Tue, 21 Oct 2014 17:11:14 +0200

> If the goal is also to prevent losing notification (Oliver’s problem),
> draft-koster-core-coapmq is something to look into.

For sure this avoids loss of information but it does not avoid loss of
actuality. There are certain use cases where you want the information in
(or close to) real-time and not at some time in the future.

You e.g. want to know that your home is burning at the time the fire
starts (or even before) and not that it was burning hours ago...

> A problem I see with the mirror proxy is that I will not work for
> actuation, i.e., in the case we want to send commands to a device with
> changing addresses.

> Comments on Oliver’s proposal: As Hannes mentioned, an IP address change
> will require a new DTLS handshake and message matching is only allowed
> within the same security context (IIRC). Hence, the client is required
> to re-register anyway.

Thank you! I didn't know that. Is that procedure already standardized or
still in draft status? Could you provide me with a link to the relevant
document(s)?

> The 24h you mentioned are for something
> different; the client can re-register whenever it wants to and the
> Max-Age is a good hint for the time span to expect a notification.

Sure, but by strictly following the standards (CoAP core and observe) a
client wouldn't know that it was the observed server but with a new
source IP that sent an update notification. Thus, the notification is
either ignored or answered with an RST that causes the server to stop
the observation. However, the client keeps the observation running for
up to 24 hours (CON notification timeout). The client does not detect a
need to restart the observation with the new server IP.

Furthermore, as you said the max-age option can only be considered a
hint. Taking the example from above you would probably set the max-age
of the status "house is not burning" to a rather high value as this
status is likely to be valid for a long time and you want to avoid
frequent update notifications. However, you want to be as sure as
possible that your observation is still running despite long max-age
values and despite any need for new DTLS handshakes. You just want to be
notified also about unexpected changes ("house is burning") before
max-age ends. And my proposal also aims to increase that certainty.

However, in a previous draft of observe it was mandatory to send new
update notifications whenever the last max-age ends (independent from a
status change). This was changed for some (probably good) reason.

> As stated above, message queueing is a much better approach to prevent
> information loss (although it conflicts with the eventual consistency
> philosophy of Observe, but it gets the job done for the use cases…).

Apparently not all of them. See above...

Best,
Oliver

> *From:*core [mailto:[email-masked]] *On Behalf Of *Floris Van den
> Abeele
> *Sent:* Montag, 20. Oktober 2014 16:58
> *To:* [email-masked]
> *Subject:* Re: [core] CoAP Endpoint Identification
> 
>  
> 
>         Cc: [email-masked] <mailto:[email-masked]>
> 
>         Likepeng <[email-masked]> <mailto:[email-masked]> writes:
> 
>          
> 
>         [email-masked] <mailto:[email-masked]>
> 
>         [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>
> 

-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
    INSTITUT FÜR TELEMATIK

    Ratzeburger Allee 160
    23538 Lübeck

    Tel +49 451 500 5396
    Fax +49 451 500 5382
    [email-masked]

    www.itm.uni-luebeck.de/people/kleine

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 28 Oct 2014 07:32:18 +0000

> For sure [draft-koster-core-coapmq] avoids loss of information but it does not avoid loss of actuality.
> There are certain use cases where you want the information in (or close to) real-
> time and not at some time in the future.

You simply need to trigger the queued messages as soon as possible. The general problem remains the same: how should a device propagate an address change (without using an RD in this use case)? From there all existing mechanisms work. My main intent is to make the best (re-)use of the ecosystem and avoid many overlapping patchwork solutions. Just continuing with notifications after an address change might be a candidate, however, there is this conflict with DTLS (see below). Another question is: would you actually design a critical application like fire alarms without an RD and proper device management?

> > Comments on Oliver’s proposal: As Hannes mentioned, an IP address
> > change will require a new DTLS handshake and message matching is only
> > allowed within the same security context (IIRC). Hence, the client is
> > required to re-register anyway.
> 
> Thank you! I didn't know that. Is that procedure already standardized or still in
> draft status? Could you provide me with a link to the relevant document(s)?

See new -observe-15:
	Resources can be observed over DTLS-secured CoAP using any of the	
	security modes described in Section 9 of RFC 7252. The use of DTLS	
	is indicated by the "coaps" URI scheme. All notifications resulting	
	from a GET request with an Observe Option MUST be returned within the	
	same epoch of the same connection as the request.

> However, the client
> keeps the observation running for up to 24 hours (CON notification timeout).

No, the 24 hours correspond to servers. It is the maximum interval a server MUST check the presence/interest of observers with a CON notification. Clients can fold their interest at any time, even without telling the server.

> The client does not detect a need to restart the observation with the new server
> IP.

The main problem is how the client can learn about the new address (see general problem above).

> However, in a previous draft of observe it was mandatory to send new update
> notifications whenever the last max-age ends (independent from a status
> change). This was changed for some (probably good) reason.

The reason is that a client can never be sure why it did not receive a notification (there was no change, the message was lost, the server is down). In some sense, every solution for this ultimately results in frequent polling of the server. With the current solution, the application can decide how critical the notifications are. If it is critical, the client can re-register directly after Max-Age ends (which can be set very low by the server). Otherwise, the client only acts when the application wants to access the current representation: either it still has a fresh one or re-registers when it is stale (Max-Age ended).

Ciao
Matthias