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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]> Im Auftrag von Carsten Bormann
    Gesendet: Freitag, 29. November 2019 13:08
    An: Christer Holmberg <christer.holmberg=[e-mail]>
    Cc: [e-mail]
    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=[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
    
    _______________________________________________
    core mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/core