Does the ack for ConfiredDataDown comes as UnconfirmedDataUp. If yes, should it be having a fcnt. When we subscribe to mqtt topic for ack, it does not have a fcnt and only the reference to the downlink sent.
It depends on your device firmware. But in most cases yes, the ack (doesn’t matter, up or down) should be unconfirmed. Otherewise there will be a good chace for a dead loop.
Surely.
Guess there’s no payload in your ack messages?
The problem is that the node does not include the FCnt of the frame that was acknowledged (which is a security issue in LoRaWAN 1.0.x, see also https://medium.com/@brocaar/notes-on-lorawan-security-7e741a8ee4fa).
Before scheduling the downlink payload you don’t know the downlink FCnt, hence the reference 
Ohk, I got this.
But, we can see an unconfirmedDataDown with a fcnt, which is not published over mqtt. It creates a confusion as there is a fCnt gap in uplink whenever confirmed downlink is sent.
Can you help me figure out this problem?
Please note, for uplink, the fCnt relates to the uplink counter, for downlink the fCnt relates to the downlink counter. It is perfectly valid that an uplink frame is not published over MQTT. If it does not contain a fPort and frmPayload the frame will be handled only by LoRa Server (there is no application payload). However, if such a frame contains an ack, then this ack is forwarded to LoRa App Server. So in this case you see the acknowledgement, but no other MQTT message.