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

[Carsten Bormann <[e-mail]>]

On Nov 29, 2019, at 14:34, Kraus Achim (INST/ECS4) <[e-mail]> wrote:
> 
> Hi Carsten,
> 
>> It does not mean the separate response is automatically retransmitted (that has its own ACK cycle).
> 
> though you're the author, I'm sure you know the intention :-).
> 
> Only resending the ACK, may keep the exchange open on the client side.
> I'm wondering, in which use-case this would be preferred over resending the flight, 
> which completes the exchange on the client side. 
> I hope my interpretation, that the decision is left to the implementation, is right? 

Well, yes, but you also need to consider congestion control.  
So I would not be too liberal about sending duplicate messages for the response side (at least I would make sure that the early resend counts against the outstanding retransmissions and triggers the exponential backoff in the same way as a retransmission — the sender should, of course, also go into exponential backoff, so this will be mostly OK then).
If there is an RTT estimate (CoCoA/Fasor), I’d also not send a duplicate if the RTT (RTO actually) has not elapsed since the last message was sent; the original message still has a good chance to arrive then.

Grüße, Carsten