Let's review the Internet.
Internet is a packet-switched network, where layer 3, aka IP, is packet-based best effort delivery service. There is no such thing as layer 3 acknowledgements in the Internet. So, routers do not acknowledge. There are ICMP messages that can be sent to the sender in case of failures, but they do not affect what happens to the packet in question.
In Internet, reliable packet delivery, if necessary is usually done by transport layer (layer 4). Transport layer (at least in theory) only works on two end-points, and all transport layer ACKs and retransmissions only happen on the sender and on the receiver, not on the systems in between. You can read the paper End-to-End Argument in System Design, if you want to know why does it work like this.
Now, the data link layer. Best-effort packet service can work on top of any data link layer, so the data link layer can be either reliable or unreliabe/best effort. As a rule of thumb, it makes sense to have a reliable layer 2 if packet errors (any event that causes the packet to not be delivered correctly) are too frequent. This usually translates into - wired layer 2 is best effort and wireless layer 2 is reliable. Also note, that wireless layer 2 usually only occure on the edge, i.e., between end-points and their first routers. If layer 2 is reliable, then acknowledgements and retransmissions happen between two layer 2 end-points. Note that, layer 2 has its own acknowledgements, which are independent of the acknowledgements of the transport layer. So, if data link layer between R3 and receiver is reliable, then data link layer of R3 will have to store the packet untill it receives an ACK and retransmit it several times if necessary. The same would happen between R2 and R3, but unless we are in a wireless mesh network, it is highly unlikely that data link layer is reliable.
Now to host issues, checksums and co.
Question:3 Now data reach at DLL at receiver side. My question is data travelling travelling through DLL to TL data loss is possible?
Yes. Every layer at the receiver has processing queues with finite space in them. If there is no space to the packet it could be dropped.
On reliable layer 2 you would probably employ some form of flow control. On unreliable layer 2, network card can drop packets, if its queue is full and the host system did not pick packets up in time.
I came across a situation where linux TCP receiver has dropped packets, despite having advertised space in receiver window. It takes too much to explain and is out of scope here, but, importantly it does not violate the specification.
If DLL didn't get acknowledgement from transport layer at receiver side then data is resend from DLL to transport layer at receiver side or data is resend from sender DLL or sender transport layer to the receiver DLL through TL?
In theory, DLL does not get or process acknowledgements from transport layer. Reliable layer 2 will employ its own acknowledgements. Acknowledgements from transport layer are treated as abstract packets with content. So, missing DLL acknowledgments are processed by DLL peer, which is R3 in your examples. Missing transport layer acknowledgments are processed by TL at the sender.
In practice, it is not quite this simple. TCP performance on networks with losses is quite suboptimal (mostly due to reasons that have something to do with congestion control). This is why wireless is usually reliable. Also wireless access points will most likely employ some kind of optimizations that monitor TCP flows. I would say that this optimization does not really fit in the OSI model. Also this is performance optimization. Network is supposed to work if you turn it off.
Question:4 If reordering is happen in DLL at receiver side then transport layer always also get in-order data, there is no necessity of sorting at transport layer?
No. Again, layer 3 is best effort, and can reorder packets. This means layer 4 should be prepared to receive out-of-order packets and sort them out. Whatever layer 2 can guarantee, layer 3 will not guarantee this, and transport layer has to deal with this.
Packets can travel different routes. This can happen if the route changes. This can also happen if one of the routers does some sort of load balancing along multiple paths (e.g., (equal cost)-multiple paths). Recall, that in packet switched networks each packet is routed independently of what happened with the previous packet.
In practice, again, since everyone is using TCP it is desirable to design layer 3 and layer 2 to avoid reordering of packets of the same transport layer flow. Routers usually do load balancing so that packets of the same flow (identified by ip addresses/ports/protocol tuple) are routed on the same path. Again, this is an optimization that affects performance. Transport layer is supposed to be fully functional if this is not done.
Another quite bizzare example are receivers with multi-core processors, aka almost any end-point right now. Packets are processed by cores in parallel, and two packets processed by two different cores can arrive in arbitrary order at the receiver transport layer. Again, usually network cards inspect transport flows and ensure that packets of the same flow are processed by the same core, but I saw situations where it did not happen.