Re: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response

Hi Wojciech,

On Tue, Feb 08, 2022 at 02:12:33PM +0000, Drewek, Wojciech wrote:

quoted

Remember, GTP-U uses different IP addresses and also typically completely
different hosts/systems, so having GTP-C connectivity between two GSN
doesn't say anything about the GTP-U path.

Two  approaches come to mind.
The first one assumes that peers are stored in kernel as PDP contexts in
gtp_dev (tid_hash and addr_hash). Then we could enable a watchdog
that could in regular intervals (defined by the user) send echo requests
to all peers.

Interesting proposal.  However, it raises the next question of what to do if
the path is deemed to be lost (N out of M recent echo requests unanswered)? It
would have to notify the userspace daemon (control plane) via a netlink event
or the like.  So at that point you need to implement some special processing in
that userspace daemon...

In the second one user could trigger echo request from userspace
(using new genl cmd) at any time. However this approach would require that
some userspace daemon would implement triggering this command.

I think this is the better approach.  It keeps a lot of logic like timeouts,
frequency of transmission, determining when a path is considered dead, ... out
of the kernel, where it doesn't need to be.

What do you think?

As both approaches require some support from the userspace control plane instance,
I would argue that the second proposal is superior.

Regards,
	Harald

-- 
- Harald Welte [off-list ref]            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)