I'm guessing the clientside fps would need to be factored in but I doubt it will ever drop below 60.
You should separate your graphics and your physics simulation rates.
are you referring to how the server will "hold" a command until the 50ms mark and then send the update packet and therefore it has been seen?
Yes, and the same for commands client-to-server (typically.)
Also, clients will send input commands to the server, and the server will then repeat those out to all other clients, so the other clients can simulate the original clients actions.
You will also need some amount of de-jitter buffer, where commands are queued for a particular tick, that may be in the future or past of where you are now. When the command is for the "past" it means the packet arrived "too late" and you need to increase your estimate of latency / jitter. When commands arrive for "way" into the future, it means your estimate is wrong the other way.