Sending data of balls transform over network regularly within an Update(), which seems too expensive computationally!
There's only 16 balls. How do you think a 16-player FPS game does networking?
Just sending the force vector over network at hit and let the physics engine handle all the physics computation based on the force vector .But i don't know how accurate will it be!
It is true that Unity doesn't use a deterministic simulation engine, and thus it doesn't allow you to ONLY send impact forces.
If I were to do pool on Unity, I'd probably send entity updates (position, orientation, velocity, spin) a dozen times per second, but I would also send special "impact events" whenever cue balls impact each other, that contain the exact position and direction of the balls affected by the impact.
However, I think the Unity physics networking code may already solve these things for you.
There's a great way for you to answer the questions you have:
1) Do some back-of-the-envelope math. How big is an update? 12 bytes pos, 12 bytes ori, 12 bytes velocity, 12 bytes spin, 4 bytes object ID? That's 52 bytes. Times 16 balls, equals 832 bytes. Less than a kilobyte for a full update. Send this 20 times a second, and you have less than 20 kB/sec per player (which is about 200 kbit/sec per player, give or take a bit of protocol overhead and rounding.) Seems plausible that it could work.
2) Actually implement it, and see how it goes. Especially, if there are already physics-based Unity game examples, use whatever API they're using and put a pool table together with 16 spheres. It doesn't need to be great gameplay, just a physics simulation experiment. Then see how it works. This kind of "spike" is very common in development and serves to inform decisions before a bigger effort is put into a particular direction.