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

[Christer Holmberg <[e-mail]>]

Hi,

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

    Whether it is a problem or not I guess depends on the use-case, but I assume one would use confirmable responses it is critical to receive each notification.

    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.

    Correct, so in normal situations the server should not receive retransmits of the request once it sends the response. But, it could happen if a request retransmit has got "stucked" in the network somewhere.

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

    I think it would be good if that is explicitly written in the RFC, because in many other protocols receiving a retransmit of a request *will* trigger a retransmit of the response.

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

    If the ACK does get lost, and the client receives the response, will it stop retransmitting 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.
    >
    > That is indeed not intended.  Retransmissions happen at the message layer.  Request/response is a layer above and is not concerned with retransmissions.

    Detecting of a request retransmit also happens at the message layer.

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

    That is not mentioned anywhere.

    And, now I am also back at another issue I had: sending retransmits that are not identical, having no clue whether the remote peer is going to detect it...
     
    >> 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.

But, if I understand correctly, in this case the server does not know whether a request is a retransmit or not.
     
    >> 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”.

I am referring to the server. If the server processes each retransmit as a separate request, in theory it might mean that each ACK will be different (since the server does not keep track of the ACK triggered by the previous request retransmit).

Regards,

Christer