50ms latency is a very low latency for non-LAN online games. I'd assume that unless all your players are in the same nearby region (think US state or EU small country), you won't ever get those numbers. [The theoretical minimum across the US (speed of light, ~36ms) doesn't account for Verizon].
I don't know what your game is, but you are probably better off making a client/server system that is resilient to 100-300ms latency (there are tons of techniques out there to help with this, like movement prediction, etc, etc..) than trying to over-optimize those 16ms of the frame wait.
THAT SAID, one thing I've seen being done on old games (that either had a FPS lock or assumed they weren't able to run above 30fps), like Quake, is to call the network update code (and the input code) multiple times during a frame. Since flash is event based (as opposed to pooling based), one option would be: inside your input events, check how long has it been since the last network update, and then decide that if it has been a few ms already, update the network.
Remember that if you are on TCP, there are other micro-optimizations that may help: like TCP_NODELAY and making sure you are not chocking on waiting for ACKs. For UDP (and also for TCP), make sure you have a reasonable packet size (compared to the MTU).