Bug #5485
closed
Make T3-RESPONSE and N3-REQUESTS configurable
Added by pespin over 2 years ago.
Updated about 1 year ago.
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.
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.
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;
- 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)
- 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.
- Status changed from Stalled to Feedback
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF