Subject: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 28 Mar 2012 10:46:32 +0200

Dear WG,

while re-reading the coap spec for WGLC, I noticed that a mixed NON/CON
message exchanges is permitted by the spec. E.g., see this text in Section
2.2:

   Likewise, if a request is sent in a Non-Confirmable message, then the
   response is usually sent using a new Non-Confirmable message,
   although the server may send a Confirmable message.  This type of
   exchange is illustrated in Figure 6.

In other words these exchanges seems to be permitted:

C     S   ||   C     S
| CON |   ||   | NON |
|---->|   ||   |---->|
| ACK |   ||   | CON |
|<----|   ||   |<----|
| NON |   ||   | ACK |
|<----|   ||   |---->|

>From a client perspective, supporting a server responding in this way may
introduce complexity.

Does someone has an implementation supporting this? Anyone has some
experience with this?

Best,
Angelo

p.s.: I think that I have to update my FSM drawing to include this option
too.

---

From: Likepeng <[email-masked]>
Date: Wed, 28 Mar 2012 09:04:23 +0000

>Does someone has an implementation supporting this? Anyone has some experience with this?

In our implementation, we support first one, not the second one.

The first flow is mainly used in observe relationship establishment. First CON is to create observe relationship, second NON is to send notifications.

I am not sure what is the use case for the second flow.

Kepeng

________________________________
发件人: [email-masked] [[email-masked]] 代表 Angelo P. Castellani [[email-masked]]
发送时间: 2012年3月28日 16:46
到: core
主题: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses

Dear WG,

while re-reading the coap spec for WGLC, I noticed that a mixed NON/CON message exchanges is permitted by the spec. E.g., see this text in Section 2.2:

C     S   ||   C     S
| CON |   ||   | NON |
|---->|   ||   |---->|
| ACK |   ||   | CON |
|<----|   ||   |<----|
| NON |   ||   | ACK |
|<----|   ||   |---->|

From a client perspective, supporting a server responding in this way may introduce complexity.

Does someone has an implementation supporting this? Anyone has some experience with this?

Best,
Angelo

p.s.: I think that I have to update my FSM drawing to include this option too.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 28 Mar 2012 11:22:05 +0200

Right, supporting observe requires you to support this exchange.

Does that work even if the first ACK is empty? Said in another way, do you
support establishing an Observe relationship even when that is done using a
separate response arriving in a NON message?

Do you support it even if that happens during a regular request/response
exchange (no Observe)?

There is nothing wrong with this. I am dubious that this changes the FSM,
so I was wondering if you support this, if it has required specific support
for this case, and your overall experience in implementing it (from a
complexity point-of-view).

Best,
Angelo

On Wed, Mar 28, 2012 at 11:04, Likepeng <[email-masked]> wrote:

> The first flow is mainly used in observe relationship establishment. First
> CON is to create observe relationship, second NON is to send notifications.
>
>

---

From: Likepeng <[email-masked]>
Date: Wed, 28 Mar 2012 10:08:34 +0000

> Does that work even if the first ACK is empty? Said in another way, do you support establishing an Observe relationship even when that is done using a separate response arriving in a NON message?

No, if there is no ACK, the observe establishment is not successful, and client can't understand the next NON message.

> Do you support it even if that happens during a regular request/response exchange (no Observe)?

No. When client sends a CON, it expects an ACK or piggy-backed response, or a RST. If no, client will retransmit, and after retransmission, give up.

Kepeng

________________________________
发件人: [email-masked] [[email-masked]] 代表 Angelo P. Castellani [[email-masked]]
发送时间: 2012年3月28日 17:22
到: Likepeng
Cc: core
主题: Re: [core] draft-ietf-core-coap-09: Mixed NON/CON separate responses

Does that work even if the first ACK is empty? Said in another way, do you support establishing an Observe relationship even when that is done using a separate response arriving in a NON message?

Do you support it even if that happens during a regular request/response exchange (no Observe)?

There is nothing wrong with this. I am dubious that this changes the FSM, so I was wondering if you support this, if it has required specific support for this case, and your overall experience in implementing it (from a complexity point-of-view).

Best,
Angelo

On Wed, Mar 28, 2012 at 11:04, Likepeng <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 28 Mar 2012 12:45:08 +0200

> Does someone has an implementation supporting this? Anyone has some experience with this?

If you properly separate off the message layer, it becomes hard work not to support this.

Grüße, Carsten

---

From: Jeroen Hoebeke <[email-masked]>
Date: Wed, 28 Mar 2012 13:59:32 +0200

> If you properly separate off the message layer, it becomes hard work not to support this.

I agree with that. Both cases are supported by default in our implementation.
When making a request, we have two basic things to check:
1) is the message acknowledged (only needed for CON)
2) did the response arrive (request/response matching)

In case 1, the ACK will fulfill 1 and the NON will fulfill 2, completing the request
In case 2, the CON will automatically result in an ACK response and the response processing will fulfill 2 (1 does not apply here, since the request is NON).

Even when in case 1, the ACK and NON arrive in a different order, the end result will be the same. You will just follow an alternative path in your state machine.

C     S   ||   C     S
| CON |   ||   | NON |
|---->|   ||   |---->|
| ACK |   ||   | CON |
|<----|   ||   |<----|
| NON |   ||   | ACK |
|<----|   ||   |---->|

Kind regards,
Jeroen

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 28 Mar 2012 16:09:46 +0200

OK. You have convinced me, I have also drawn a FSM supporting this (see
related separate response thread).

I hope to have time to implement it and get back with comments.

Best,
Angelo

On Wed, Mar 28, 2012 at 13:59, Jeroen Hoebeke <[email-masked]
> wrote:

> In case 2, the CON will automatically result in an ACK response and the
> response processing will fulfill 2 (1 does not apply here, since the
> request is NON).
>
> Even when in case 1, the ACK and NON arrive in a different order, the end
> result will be the same. You will just follow an alternative path in your
> state machine.
>
>
> C     S   ||   C     S
> | CON |   ||   | NON |
> |---->|   ||   |---->|
> | ACK |   ||   | CON |
> |<----|   ||   |<----|
> | NON |   ||   | ACK |
> |<----|   ||   |---->|
>
>
>
> Kind regards,
> Jeroen
>
>
>
>
>