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

From: Christer Holmberg <[email-masked]>
Date: Mon, 2 Dec 2019 09:16:37 +0000

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 2 Dec 2019 15:58:03 +0000

Hi Kraus,
    
>    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.

How does the stack know if the outcome will be the same? 

And, what is the definition of "acceptable difference"?

>    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.
  
I am not sure what you mean by "original message as answer". Are you referring to an ACK, or to a response message?
    
>    Q1. "Perhaps I have missed it" => I think page 34 top specifies that.
  
Where?

I can only find text saying that another ACK is sent is a request retransmit is received.
   
>    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. 
  
The issue is that the responses may not be identical, as the server does not keep track of previously sent responses.

Regards,

Christer

    -----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,
    
    > On Nov 29, 2019, at 09:44, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
    > 
    > Hi,
    >  
    > A couple of questions for clarification.
    >  
    >  
    
    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.

    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.

    

     

    
    
    Grüße, Carsten
    
    _______________________________________________
    core mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/core

---

From: Achim Kraus <[email-masked]>
Date: Mon, 2 Dec 2019 20:16:37 +0100

Hi Christer,

 >>     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
 > How does the stack know if the outcome will be the same?

Your sequence:
1 - CON request
2 - ACK
3 - NON response

With that, the outcome is:
the request (may) have been answered once with the response

4 - CON request (re transmission)
5 - ACK (re transmission)
6 - NON response (re transmission)

With that re transmitted flight, the outcome is:
the request (may) have been also answered once with the response.
(At least, it's possible to implement the response re receive in that way.)

The difference not re transmitting the response, is that the may would
get less probable. Or do I misunderstand your question?

 > And, what is the definition of "acceptable difference"?

That depends on your application. That is a cascade of relaxing the
consideration for peers, which are not able to operate as preferred.
Best 1 - use storage to re transmit the message from
Next 2 - call the application layer to get the same message for re
transmission.
Next 3 - call the application layer to get the similar message for re
transmission.

The point is, that the selected implementation depends on the available
resources. If it's only "Best - 1", then all peers would require to have
enough storage. Relaxing that, makes it possible to operate on smaller
devices with less footprint.

 >>     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."
 > I am not sure what you mean by "original message as answer". Are you
referring to an ACK, or to a response message?
 > I can only find text saying that another ACK is sent is a request
retransmit is received.

That was my wrong interpretation of

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

Carsten, the author, already explained his intention, which is obviously
the right on :-).

 >
 >>     Q2: That's the responsibility of the application to choose the
right tradeoff between resources consumption and complying to the
expectations.
 > The issue is that the responses may not be identical, as the server
does not keep track of previously sent responses.

I don't get that. My feeling your implementing a stack, which interacts
with the application layer. The specification sometimes relax the
requirements for the stack and push them to the application layer. With
that, the stack is not longer responsible, it's the application layer.
And there is sure no general answer to the questions, what will be, if
that application layer doesn't comply to the expectations. I would
think, that it's up to the application layer implementors to chose the
right, fitting into the resources and works for their use-case.

Best regards
Achim