Subject: [core] Retransmission of non-confirmable response message upon receiving request message retranmission?

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Nov 2019 08:44:44 +0000

Hi,

A couple of questions for clarification.

Assume a CoAP server receives a confirmable request message.

According to Section 4.5. of RFC 7252, the server SHOULD retransmit the associated ACK whenever it receives a retransmission of the request message. So far, so good.

Then, assume that the sever sends a non-confirmable response message to the request. AFAIK, that is allowed.

---

Q1:

Perhaps I have missed it, I can’t find any text saying that the server would retransmit the response message if it receives a retransmission of the request. Section 4.3 does say that a server may choose to transmit multiple copies of a non-confirmable message, but there is no text saying that such transmits would be triggered by a retransmission of the request.

Section 4.5. does say:

     “A server might relax the requirement to answer all retransmissions
      of an idempotent request with the same response (Section 4.2),”

Where does Section 4.2 talk about answering retransmissions of an idempotent request (or any request, for that matter) with the same response?

---

Q2:

Related to Q1, Section 4.5 says:

      ”For example, an implementation might want to process duplicate
      transmissions of a GET, PUT, or DELETE request as separate
      requests if the effort incurred by duplicate processing is less
      expensive than keeping track of previous responses would be.”

Maybe I misunderstand this “process as separate requests” thing, but:

First, it means that each response could be different from the previous one, and the sender of the request would have to process each of them.

Second, does this mean that, if the responses are confirmable, the server should expect an ACK for each response? “Process as separate requests” makes it sound like that.

---

Regards,

Christer

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Nov 2019 13:08:29 +0100

Hi Christer,

> On Nov 29, 2019, at 09:44, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> Hi,
>  

Allowed, yes, but also a rather unusual case: The client took care to send a confirmable request, and the server only answers unreliably.  This combination makes the most sense for an observe-GET, where the server is sending periodic notifications, so the loss of a single one is not really a big problem.

> ---
>  
> Q1:
>  
> Perhaps I have missed it, I can’t find any text saying that the server would retransmit the response message if it receives a retransmission of the request. 

No, it won’t.  The client will retransmit only up to receiving an ACK.
Since your scenario assumes non-confirmable responses, this implies a separate response, so the ACK will be empty.  The server can then send, at leisure, its response; no further retranmissions will take place.

(A weird case is where all ACKs get lost and finally the response indicates to the client that the request must have arrived, stopping retransmission — see penultimate paragraph of 4.2.  Still, the message-id of all retransmissions is the same, so no additional response will be generated.)

> Section 4.3 does say that a server may choose to transmit multiple copies of a non-confirmable message, but there is no text saying that such transmits would be triggered by a retransmission of the request.

That is indeed not intended.  Retransmissions happen at the message layer.  Request/response is a layer above and is not concerned with retransmissions.
 
>       of an idempotent request with the same response (Section 4.2),”

Now you are back to piggybacked responses.
 
> Where does Section 4.2 talk about answering retransmissions of an idempotent request (or any request, for that matter) with the same response?

Good question.  Interesting.
 
> First, it means that each response could be different from the previous one, and the sender of the request would have to process each of them.

The sender is not supposed to retransmit a request if it already received a response.
Of course, the retransmission and the response might cross; in this case the superfluous response is not used.
 
> Second, does this mean that, if the responses are confirmable, the server should expect an ACK for each response? “Process as separate requests” makes it sound like that.

If the response is sent as a confirmable message, the server expects an ACK for it.  It retransmits until it gets one.
If the response is in an ACK, it is not confirmable; this is really the useful case for “process as separate requests”.

Grüße, Carsten

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Fri, 29 Nov 2019 12:20:17 +0000

Hi Christer,

(sorry I missed to answer the list, so retransmitting my e-mail):
 
from my experience as one of the Eclipse/Californium developer:

Section 4 is about transmission (CON, NON,ACK and RST), and only slight refer to section 5 (request/response). For that FMPOV it seems to be clear, that if a retransmission is detected, the receiver should do its best the send back the same answer, in your case the empty ACK. 
In my interpretation of Section 4.5 the intention is, that the retransmission should be handled best on the transmission layer and should not be visible/forwarded to the request/response layer. That maybe relaxed, if the outcome is the same or shows only acceptable difference. Generally, the messages (flight) of the original answer are intended to be retransmitted.

Section 5 is then about the request/response 5.2.2, page 34 (top), "If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another Empty Acknowledgement is sent, and any response MUST be sent as a separate response."
That seem to point to the same intention: retransmit the original messages (flight) as answer.

(It seems that my understanding differs from Carsten's answer.)

Q1. "Perhaps I have missed it" => I think page 34 top specifies that.
 
Q2: That's the responsibility of the application to choose the right tradeoff between resources consumption and complying to the expectations.
If the difference is larger, your application must be designed for that. 

Mit freundlichen Grüßen / Best regards 

Achim Kraus

Mit freundlichen Grüßen / Best regards

Achim Kraus

Engineering Cloud Services 4 Bosch IoT Hub (INST/ECS4) 
Tel. +49 711 811-58139 | Fax +49 711 811-58200 | [email-masked]

-----Ursprüngliche Nachricht-----
Von: core <[email-masked]> Im Auftrag von Carsten Bormann
Gesendet: Freitag, 29. November 2019 13:08
An: Christer Holmberg <christer.holmberg=[email-masked]>
Cc: [email-masked]
Betreff: Re: [core] Retransmission of non-confirmable response message upon receiving request message retranmission?

Hi Christer,

 

 

Grüße, Carsten

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Nov 2019 13:27:49 +0100

> (It seems that my understanding differs from Carsten’s answer.)

   When the server chooses to use a separate response, it sends the
   Acknowledgement to the Confirmable request as an Empty message.  Once
   the server sends back an Empty Acknowledgement, it MUST NOT send back

Shelby, et al.               Standards Track                   [Page 33]
RFC 7252       The Constrained Application Protocol (CoAP)     June 2014

   the response in another Acknowledgement, even if the client
   retransmits another identical request.  If a retransmitted request is
   received (perhaps because the original Acknowledgement was delayed),
   another Empty Acknowledgement is sent, and any response MUST be sent
   as a separate response.

This means that once the server sends an empty ACK, it is committed to replying in a separate response; it can’t go back to piggybacking, even if a conveniently arriving retransmission of the request might suggest so.  It does not mean the separate response is automatically retransmitted (that has its own ACK cycle).

Grüße, Carsten

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Fri, 29 Nov 2019 13:34:48 +0000

Hi Carsten,

>  It does not mean the separate response is automatically retransmitted (that has its own ACK cycle).

though you're the author, I'm sure you know the intention :-).

Only resending the ACK, may keep the exchange open on the client side.
I'm wondering, in which use-case this would be preferred over resending the flight, 
which completes the exchange on the client side. 
I hope my interpretation, that the decision is left to the implementation, is right? 

Achim Kraus

-----Ursprüngliche Nachricht-----
Von: Carsten Bormann <[email-masked]> 
Gesendet: Freitag, 29. November 2019 13:28
An: Kraus Achim (INST/ECS4) <[email-masked]>
Cc: Christer Holmberg <christer.holmberg=[email-masked]>; [email-masked]
Betreff: Re: [core] Retransmission of non-confirmable response message upon receiving request message retranmission?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Nov 2019 14:55:39 +0100

> I hope my interpretation, that the decision is left to the implementation, is right? 

Well, yes, but you also need to consider congestion control.  
So I would not be too liberal about sending duplicate messages for the response side (at least I would make sure that the early resend counts against the outstanding retransmissions and triggers the exponential backoff in the same way as a retransmission — the sender should, of course, also go into exponential backoff, so this will be mostly OK then).
If there is an RTT estimate (CoCoA/Fasor), I’d also not send a duplicate if the RTT (RTO actually) has not elapsed since the last message was sent; the original message still has a good chance to arrive then.

Grüße, Carsten