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

[Harald Welte <laforge@osmocom.org>]

Hi Wojciech,

On Tue, Feb 08, 2022 at 02:12:33PM +0000, Drewek, Wojciech wrote:
> > 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 <laforge@osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)