sending ~700Kb for 5 minutes translates to ~2.3kb/s. that's not too bad for a game(using a deterministic game setup with sending only inputs can get you down into the byte range depending on how frequently you send inputs.)

receiving ~700Kb for 2 minutes translates to ~5.9kb/s. still not terrible for a game. if you don't have central game servers and have a player act as the host, then this setup can be usable over the internet pretty easily(with a dozen or so players at a time). however if you have a Central server to facilitate all your games, then you'll likely want to reduce the amount of bandwidth used by an individual client, as even a few dozen of clients can add up and saturate your bandwidth very quickly.

Note that 125 fps for network traffic is generally way more than optimal. 20 or 30 Hz network packets is usually quite enough. Even twitch-action games with custom servers, like high-end Counter-Strike games, will seldom have a network tick rate above 60 Hz.

Note that there are likely three frame rates in your game:

1) The rendering frame rate.
2) The simulation/physics frame rate.
3) The network packet frame rate.

These are typically all de-coupled from each other. You can separately use multiple mechanisms, such as "display latest" or "interpolate between two latest" or "extrapolate from latest," to go from network to simulation, or simulation to display.

For each network tick, you will typically collect all the player input that has been seen for all simulation ticks since the last network tick. You may also collect the latest state dump of objects being updated, and/or events that have been generated since the last network tick. Then send all of those messages in a single packet (with appropriate per-message timing information.)

The network packet frame rate and the simulation frame rate are typically fixed, whereas the display frame rate depends on the performance of the computer running the particular game instance.