Strange, I thought it was the other case around.
It's a neat trick that prevents much data from having to be synchronized between the clients and host:
You'd think that with hundreds of thousands of events, decisions, AI unit control, faction joining/leaving, etc. etc. all going on at once that there'd be a lot of information to be constantly synchronizing so that all clients see identical game state. However, due to the deterministic nature of a) code that's guaranteed to be the same on all clients and thus can be trusted to act the same given identical inputs, and b) random number generation (even for a million randomized events and AI choices, if all clients start with the same random number generator starting seed, they'll always make the same random decisions), multiplayer is actually a lot like singleplayer. Those thousands of AI characters / random timing / etc. are being simulated exactly the same by the same code and starting state on all clients simultaneously without the need for communication.
Think of it this way: if players in an MP game just spectated and never interacted with the game in an unpredictable fashion, there would be zero communication overhead after scenario initialization for an infinitely long campaign of a theoretically infinite amount of clients. That seems obvious when you think about it. So, the only things which require synchronization are when players do something that cannot be predicted (essentially, serve as their own black box random number generator inside the simulation). Clicking on stuff, browsing the map, etc. require no synchronization because they don't change game state. That just leaves things that only matter when players do them, called "commands," such as:
- Player takes a decision (simply the ID of the decision taken would suffice for the communication, e.g., as all the decision code is identical for everyone)
- Diplomatic interactions between players and AI or other players.
- Raise levies
- Hire retinue/change its reinforce rate
- Dismiss/disband unit
- Merge/re-balance/split unit
- Move unit from province X to province Y (the paths are all precalculated, so the whole path and progress along it will be deterministically known just from the endpoints)
- Create/destroy a title or change primary titles
- Player chooses an event option
- Auto-stop plots is enabled/disabled
- Auto-invite plotters is enabled/disabled
- Daily ticks (just a ping saying that the client has finished executing the next day of the simulation so that the host can keep clients in approximate lockstep-- the random variable is just how long it took a particular's player to finish processing the day)
- Join/create/leave/abandon a faction/ambition/plot/focus
- Pause/unpause game
Everything else can be figured out on the local machine of each client, like hitting "play" on a very big and non-traditional mathematical equation with just a few parameters that must be specified to generate a grand performance.
All in all, the only information here that isn't highly compact and extremely rarely transmitted (relative to the millions of bytes per second that most people's Internet connections have available to them) and that's time-sensitive is making sure that unit movements are kept very well in sync (which is more of a latency problem, assuming perfectly equivalent computer speeds).
One of my specialties is writing networking code (with some time spent on games in addition to real-time distributed systems control and the like), so I've just come to these conclusions on my own due to my non-Paradox understanding and experience of the nature of the engine, and thus I think is the way the engine
should be handling things. I could be wrong. It could be very poorly implemented, after all.
This is the reason that CK2 supports 32 simultaneous players (and EU4 256) in theory. It's the simulation itself that's super slow, and that's the main problem in singleplayer as well. Local client processing time will strongly dominate any extra processing due to multiplayer (except for the host, but again, that's just more processing and not so much about transmission).
That said, lower latency and higher bandwidth connections are always better.