If this is what I think you are asking, what you would want to do is
calculate the amount of data you are writing into your logical logs,
which you can roughly do looking at the time it takes you to complete
a logical log from the messages in the online.log and then knowing how
big they are.  From those two things you could get a rough amount of
bytes/sec that would need to be sent from your primary machine to your
secondary machine.

,
If the network restricts the rate at which you can send your data to
the secondary (you generate more log data then can be sent), you would
start to see some bottlenecking on access to the logical logs likely
(more threads waiting to access the logical log and thus slower write
activity on the primary), and then also your checkpoint duration would
also spike up.  As the checkpoint record needs to be sent to the
secondary and ack'd before it can complete on the primary and so there
would be a bit of a backlog of data to be sent before the checkpoint
could be sent.  That backlog time would be included in the checkpoint
duration.

Depends on if you use HDR in the sync or async setting.  If you are
using sync, then every logical log buffer flush that occurs on the
primary has to be ack'd by the secondary before the log buffer flush
completes on the primary.  So the most that a sync HDR pair would lose
is whatever was in the current logical log buffer on the primary when
it crashed.  If you are using async mode the logical log buffer
flushes in the primary don't need to be sent and ack'd before
continueing.  In this case there are 12 buffers (of logical log buffer
size) on the primary that are used to store logical log buffer data
that could be full and waiting to be sent, so then that would be the
largest amount of data your secondary server would not receive if your
primary crashed with all 12 of those buffers full.

Jacques