If you asked us to send a message right now, how long would that message
sit in the queue before we actually started putting packets on the wire?
(And assuming Nagle does not cause any packets to be delayed.)
In general, data that is sent by the application is limited by the
bandwidth of the channel. If you send data faster than this, it must
be queued and put on the wire at a metered rate. Even sending a small amount
of data (e.g. a few MTU, say ~3k) will require some of the data to be delayed
a bit.
In general, the estimated delay will be approximately equal to
plus or minus one MTU. It depends on how much time has elapsed since the last
packet was put on the wire. For example, the queue might have *just* been emptied,
and the last packet placed on the wire, and we are exactly up against the send
rate limit. In that case we might need to wait for one packet's worth of time to
elapse before we can send again. On the other extreme, the queue might have data
in it waiting for Nagle. (This will always be less than one packet, because as soon
as we have a complete packet we would send it.) In that case, we might be ready
to send data now, and this value will be 0.
If you asked us to send a message right now, how long would that message sit in the queue before we actually started putting packets on the wire? (And assuming Nagle does not cause any packets to be delayed.)
In general, data that is sent by the application is limited by the bandwidth of the channel. If you send data faster than this, it must be queued and put on the wire at a metered rate. Even sending a small amount of data (e.g. a few MTU, say ~3k) will require some of the data to be delayed a bit.
In general, the estimated delay will be approximately equal to
( m_cbPendingUnreliable+m_cbPendingReliable ) / m_nSendRateBytesPerSecond
plus or minus one MTU. It depends on how much time has elapsed since the last packet was put on the wire. For example, the queue might have *just* been emptied, and the last packet placed on the wire, and we are exactly up against the send rate limit. In that case we might need to wait for one packet's worth of time to elapse before we can send again. On the other extreme, the queue might have data in it waiting for Nagle. (This will always be less than one packet, because as soon as we have a complete packet we would send it.) In that case, we might be ready to send data now, and this value will be 0.