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

[Carsten Bormann <[e-mail]>]

Hi Christer,

> On Nov 29, 2019, at 09:44, Christer Holmberg <christer.holmberg=[e-mail]> wrote:
> 
> 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.

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.
 
> 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),”

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.
 
> ---
>  
> 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.

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