Attention is currently required from: laforge, neels, pespin.

View Change

1 comment:

• File src/libosmo-pfcp/pfcp_cp_peer.c:

  • Patch Set #1, Line 112:

    	unsigned int tval_rx_heartbeat_s =
    		osmo_tdef_get(cp_peer->ep->cfg.tdefs, OSMO_PFCP_TIMER_HEARTBEAT_RESP, OSMO_TDEF_S, -1);
    	o
    

    Yes, because you are expected to set "HB response timeout" to be > "HB interval".

    Where this expectation is coming from? Is this stated in the specs. somewhere?

    Anyway, I still see a problem here:

    • `tval_tx_heartbeat_s` (HB interval) = 10s
    • `tval_rx_heartbeat_s` (HB response timeout) = 15s

    Scenario:

    * [0.0s] Tx HEARTBEAT Req (initial)
     * re-schedule `heartbeat_tx_timer` (+10s, triggers @ 10.0s)
     * re-schedule `heartbeat_rx_timer` (+12s, triggers @ 12.0s)
    * [0.5s] Rx HEARTBEAT Rsp
     * re-schedule `heartbeat_rx_timer` (+12s, triggers @ 12.5s)
    * [10.0s] Tx HEARTBEAT Req
     * re-schedule `heartbeat_tx_timer` (+10s, triggers @ 20.0s)
    * [12.5s] `heartbeat_rx_timer` expires, `PFCP_CP_PEER_EV_HEARTBEAT_TIMEOUT`

    • [13.0s] Rx HEARTBEAT Rsp (late?)

    Even though the 2nd `HEARTBEAT Rsp` was received only 3.0s after the 2nd `HEARTBEAT Req` (less than the timeout of 15.0s), the timeout condition was already declared. This is why I believe the `heartbeat_rx_timer` needs to be re-scheduled when sending the `HEARTBEAT Req`.

To view, visit change 42120. To unsubscribe, or for help writing mail filters, visit settings.