Project

General

Profile

Actions

Bug #5485

closed

Make T3-RESPONSE and N3-REQUESTS configurable

Added by pespin about 2 years ago. Updated 11 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
libgtp
Target version:
-
Start date:
03/07/2022
Due date:
% Done:

100%

Spec Reference:

Description

Right now, those are hardcoded in libgtp gtp.c:

/* According to section 14.2 of 3GPP TS 29.006 version 6.9.0 */
#define N3_REQUESTS    5

#define T3_REQUEST    3

According to TS 29.060 7.6 Reliable Delivery of Signalling Messages:

The T3-RESPONSE timer shall be started when a signalling request message (for which a response has been defined) is
sent. A signalling message request or response has probably been lost if a response has not been received before the
T3-RESPONSE timer expires. The request is then retransmitted if the total number of request attempts is less than
N3-REQUESTS times. The timer shall be implemented in the control plane application as well as user plane application
for Echo Request / Echo Response. The wait time for a response (T3-RESPONSE timer value) and the number of
retries (N3-REQUESTS) shall be configurable per procedure
. The total wait time shall be shorter than the MS wait time
between retries of Attach and RA Update messages.

So according to spec it should be configurable. When it says per "per procedure", I guess it means by message type (req+resp), but I think we are fine at least having them as 1 configurable timer used for all messages.
This would be helpful for instance in TTCN3 tests, were we ideally need to wait for the retransmit resp queue (duplicate req detector) in order to avoid falling in the situation where same seqnum is reused in different tests.

Actions #1

Updated by pespin about 2 years ago

Furthermore, the timeout set to track duplicate request received (retransmit resp queue) is hardcoded to 60 seconds in libgtp gtp_resp():

        qmsg->timeout = time(NULL) + 60;    /* When to timeout */

This should ideally have its own timer, and should ideally set to smething slightly higher than T3_REQUEST*N3_REQUESTS configured at the GSN peer. In our case we could also set it to T3_REQUEST*N3_REQUESTS by default.

Actions #2

Updated by pespin about 2 years ago

pespin wrote in #note-1:

Furthermore, the timeout set to track duplicate request received (retransmit resp queue) is hardcoded to 60 seconds in libgtp gtp_resp():
[...]

This should ideally have its own timer, and should ideally set to smething slightly higher than T3_REQUEST*N3_REQUESTS configured at the GSN peer. In our case we could also set it to T3_REQUEST*N3_REQUESTS by default.

open5gs seems to be doing exactly that:

#define GTP_N3_RESPONSE_RETRY_COUNT  3
    self.time.message.gtp.n3_response_rcount = GTP_N3_RESPONSE_RETRY_COUNT;
    self.time.message.gtp.t3_response_duration =
        (self.time.message.duration /
         (self.time.message.gtp.n3_response_rcount + 1));
    ogs_assert(self.time.message.gtp.t3_response_duration);

#define GTP_N3_HOLDING_RETRY_COUNT 1
    self.time.message.gtp.n3_holding_rcount = GTP_N3_HOLDING_RETRY_COUNT;
    self.time.message.gtp.t3_holding_duration =
        self.time.message.gtp.n3_response_rcount *
        self.time.message.gtp.t3_response_duration;

Actions #3

Updated by pespin over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to pespin

Timers are made configurable through VTY in libgtp and osmo-ggsn here:
https://gerrit.osmocom.org/c/osmo-ggsn/+/29969 ggsn: Introduce tdef and make it configurable over VTY

And in osmo-sgsn here:
https://gerrit.osmocom.org/c/osmo-sgsn/+/29970 vty: Make new libgtp tdefs configurable through VTY

OsmoGGSN# show timer gtp
gtp: T3 = 3424 s    The timer T3-RESPONSE holds the maximum wait time for a response of a request message (default: 5 s)
gtp: T1003 = 999    The counter N3-REQUESTS holds the maximum number of attempts made by GTP to send a request message (default: 3)
Actions #4

Updated by pespin over 1 year ago

  • Category set to libgtp
  • Status changed from In Progress to Stalled
  • % Done changed from 0 to 90

osmo-sgsn can now also configure the parameters here:
https://gerrit.osmocom.org/c/osmo-sgsn/+/29970

I adapted a bit GGSN_Tests to be able to change the related timers:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30007

Once we have a new osmo-ggsn release with the patches merged, we can change the TTCN3 module parameters to lower values to speed up the tests, modifying accordingly the same timers in osmo-ggsn to match.

Marking as stalled now so that we can lower ther timers after osmo-ggsn >1.9.0 is released.

Actions #5

Updated by pespin over 1 year ago

Another related patch which was merged today (I forgot to push it to gerrit at the time):
https://gerrit.osmocom.org/c/osmo-ggsn/+/30279

Actions #6

Updated by pespin 12 months ago

  • Status changed from Stalled to Feedback

Patches submitted to speed up TTCN3 tests against osmo-ggsn can be found here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32283 ggsn: Speed up tests by lowering retransmission T3,N3 timers
https://gerrit.osmocom.org/c/docker-playground/+/32284 ttcn3-ggsn: Speed up tests by lowering retransmission T3,N3 timers

Once merged, this ticket can be closed.

Actions #7

Updated by pespin 11 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged, closing.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)