[asterisk-dev] [IAX] ping time calculations

[Matthew Jordan]

On Tue, Mar 24, 2015 at 4:04 PM, Yousf Ateya <y.ateya at starkbits.com> wrote:
> One of the ways in which IAX calculates peer ping time is using
> POKE/PONG/ACK sequence as follows:
>
> - Peer1 sends POKE (frame timestamp is time of sending)
> - Peer2 sends PONG with same time stamp received from POKE.
> - Peer1 calculates ping time by doing: pong_reception_time - poke_send_time.
>
> While using a shaky connection, sometimes ping time changes from normal
> ~100ms to long ping time (~2 seconds, sometimes get TOO LAGGED) for one ping
> and returns to normal again.
>
> This happens because of packet loss. Here is what happens:
>
> - Peer1 sends POKE (it mark sending time stamp in channel member `offset`)
> - POKE packet is dropped
> - After sometime (qualify / 2), POKE is retried.
> - Peer2 receives the POKE packet and sends PONG.
> - Peer1 receives the PONG packet, and calculates ping time =
> pong_receiption_time - first_poke_send_time
>
> So ping time becomes high for short period because of a packet retry, not
> because the network is slow.
>
> Is it better to calculate ping time = pong_receiption_time -
> last_poke_send_time? So we get **actual** network ping time instead of
> network_ping_time + packet_retry_time.

I'd say we should always be using the time of the POKE that
corresponds to the PONG that was received. Unfortunately, that doesn't
appear to be easy, as I don't _think_ there's a way to know which POKE
message the PONG is for - we don't send back the identity of the POKE
message that caused the PONG message. (At least from what I can tell -
I may be mistaken here.)

The only problem with your proposal is that you may get very
inaccurate qualification times. Consider a situation in which the
network is terribly lagged:

1. Send POKE #1
2. Wait, get no PONG
3. Send POKE #2
4. Get a PONG message for POKE #1

With your algorithm, we'd calculate the round trip time as PONG - POKE
#2 - which is very wrong. In fact, doing that may be more harmful than
reporting a high qualify time due to a packet getting dropped.

So I'm not sure this is the right approach - at least not without
knowing how we would correlate PONGs to POKEs in such a scenario.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org