I would recommend against using network level confirmed uplink. The way it is designed, only the first attempt which reaches a gateway is confirmed by the network. So if it’s actually the downlink packet that gets lost for whatever reason, then none of the retries will ever receive another confirmation. The network will ignore all traffic from the node until the uplink frame count increments, and retries do not increment the frame count, so they simply get ignored.
Instead, I’d suggest you implement your own confirmations at application level. This has several benefits, first each application packet gets a unique frame count, so none will be ignored by the network stack. Next, you can chose the retry strategy that is the best compromise between success and battery and airtime consumption. And whatever data you might include in the retry could be fresher measurements, rather than increasingly stale old ones. But most important, by generating an application-level downlink ack in your data backend infrastructure rather than having the TTN network servers generate a network-level one, your ack confirms what you probably actually care about - that your data back end got the message. TTN’s servers getting the message and it then getting lost on the way to your data backend is interesting from a debugging perspective, but probably irrelevant from a user one, where what you probably want is a truly end-to-end confirmation.