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

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
 >>     answer are intended to be retransmitted.
 >
 > 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."
 >>     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.

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

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

Am 02.12.19 um 16:58 schrieb Christer Holmberg:
> 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 <core-bounces@ietf.org> Im Auftrag von Carsten Bormann
>      Gesendet: Freitag, 29. November 2019 13:08
>      An: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
>      Cc: core@ietf.org
>      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=40ericsson.com@dmarc.ietf.org> 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
>
>      _______________________________________________
>      core mailing list
>      core@ietf.org
>      https://www.ietf.org/mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>