Subject: Re: [core] draft-ietf-core-coap-09: Separate response in a lossy context

From: "Kovatsch Matthias" <[email-masked]>
Date: Wed, 28 Mar 2012 07:51:28 +0000

Hi

I will describe my experience towards this point that I gained during implementation.

I think the problem is that you cannot assign these IDs at the message layer. Your IDs clearly represent a request/response pair that is identified by end-point address + token (something I also previously called a session, as a blockwise transfer could happen below this abstraction).
In your chart, the message layer can only agnosticly deliver the massage upwards and some upper instance makes the token matching (I call it the token layer).
A problem is now, who should acknowledge the incoming CON, the message layer or the token layer? As it is unlikely that this received message gets lost internally, the message layer can ACK it. If this ACK gets lost on the channel and a retransmission arrives, there are multiple options:
- The duplicate detection recognizes the message, ACKs it and does not deliver it upwards.
- There is no dup detection and the message is passed upwards. Now, the token layer will not be able to make a match, as the token "b" was already closed. So it will send a RST, but this is no problem. The server knows it did fulfill the request, the client is just not interested anymore. This does not meet a transaction-like request/response requirement, but was that the goal?

Something related at the server side that might be interesting:
A bug that we could identify in Californium was that the cache to answer detected duplicates only stored the empty ACK for an incoming message ID when separate responses were used. I will have to add a fix that updates the cached ACK with the separate response.

Ciao
Matthias

"Angelo P. Castellani" <[email-masked]> wrote:
I propose an example to better clarify my point:
           C                S
           |                |
id=0x38 |  | GET /a         | /|\
        |  | Token: "a"     |  | id=0x21
=======\|/=|================|==|=======
           | CON MID=0x1234 |
           |--------------->|
           |                |
id=0x39 |  | GET /b         | /|\
        |  | Token: "b"     |  | id=0x22
=======\|/=|================|==|=======
           | CON MID=0x1235 |
           |--------------->|
           |                | response is delayed
           |                | message layer sends
           | ACK MID=0x1235 | an empty ack
           |<---------------|
           |                |
id=0x? /|\ | 2.05 "B"       |  |
38 or 39|  | Token: "b"     |  | id=0x22
========|==|================|=\|/=======
           | CON MID=0xfefe |
           |<---------------|

Assume that the message-layer has no knowledge of the content of each message, but its knowledge is limited to an identifier univocally identifying each different conversation (previously called session).

How does the message-layer know to which identifier should the response in the example be mapped to?

Best,
Angelo

On Tue, Mar 27, 2012 at 14:02, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
On Mar 27, 2012, at 14:00, Carsten Bormann wrote:

> An ACK-0 (the one you get for a request that causes a separate response, as well as the one that asks the separate response) does not have a token.
> I believe we still have a proper separation between the retransmission/duplicate detection mechanics (based on MID) and the request/response layer.
> Can you point out where you need the token to do the matching here?
>
> I don't know what a "session" is, by the way.
>
> Grüße, Carsten

Sorry, this one was about Angelo's last message.

Grüße, Carsten

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

---

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

On Wed, Mar 28, 2012 at 09:51, Kovatsch Matthias <[email-masked]>wrote:

> I think the problem is that you cannot assign these IDs at the message
> layer. Your IDs clearly represent a request/response pair that is
> identified by end-point address + token (something I also previously called
> a session, as a blockwise transfer could happen below this abstraction).
>

Yes, I share your point of view. That was exactly my point (gained during
implementation as well) and the reason that led me to drawing the FSM based
on this concept of session/conversation, that integrates also Token
matching.

> In your chart, the message layer can only agnosticly deliver the massage
> upwards and some upper instance makes the token matching (I call it the
> token layer).

A problem is now, who should acknowledge the incoming CON, the message
> layer or the token layer? As it is unlikely that this received message gets
> lost internally, the message layer can ACK it.

If it has no state to match this, the message-layer must not ACK it...
Imagine to receive a response with Token: "c". Would you ACK it? You have
to RST it.

The upper-layer should instruct the message layer on ACKing or RSTing it,
because the message-layer has no state at all (thus neither a state machine
to handle it).

If this ACK gets lost on the channel and a retransmission arrives, there
> are multiple options:
> - There is no dup detection and the message is passed upwards. Now, the
> token layer will not be able to make a match, as the token "b" was already
> closed. So it will send a RST, but this is no problem. The server knows it
> did fulfill the request, the client is just not interested anymore. This
> does not meet a transaction-like request/response requirement, but was that
> the goal?
>

Assuming that duplicate detection is in place, as should be the case
following the specification, the real problem here is about the overall
complexity of this "duplicate detection" system.

You have to keep at least (remote IPv4 or IPv6 (!!), remote UDP port, MID,
[Message to send again])... In regular implementations keeping this state
is not a problem, on sensor nodes (class-1 HW) this is a real burden.

Something related at the server side that might be interesting:
> A bug that we could identify in Californium was that the cache to answer
> detected duplicates only stored the empty ACK for an incoming message ID
> when separate responses were used. I will have to add a fix that updates
> the cached ACK with the separate response.
>

Interesting point. Take in mind that if the implementation on the end has
get the response, but still wants the empty ACK (does not implement the
related "implementation note") will not be satisfied by your response.

Best,
Angelo

---

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

> How does the message-layer know to which identifier should the response in the example be mapped to?

The job of the message layer is to make sure confirmable messages do arrive and that duplicates are detected where that is required.
This question belongs in the request/response layer.

In other words:
This is about the same question as "how does IP forward packets without understanding port numbers".
Of course, once the message layer has done its job, the request/response layer has to look at the token to find out which exchange this message is about.

When talking about the matching that occurs at the two layers, please make sure to talk about MIDs and Tokens explicitly.  
They are different enough that this effort in clarity is worth it.

Grüße, Carsten

---

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

On Mar 28, 2012, at 10:21, Angelo P. Castellani wrote:

> The upper-layer should instruct the message layer on ACKing or RSTing it, because the message-layer has no state at all (thus neither a state machine to handle it).

Indeed.  The interface between message-layer and request/response layer is quite tightly coupled.
When an incoming message is handed up the SAP, the rr layer should say whether that message is acceptable or not and only then should the m layer generate the ACK/RST.  But you have to do something like this already for properly piggy-backing responses, so this is not a big additional burden.

Grüße, Carsten