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

Hi Harald

-----Original Message-----
From: Drewek, Wojciech
Sent: piątek, 11 lutego 2022 11:27
To: Harald Welte <redacted>
Cc: Marcin Szycik <redacted>; netdev@vger.kernel.org; michal.swiatkowski@linux.intel.com;
davem@davemloft.net; kuba@kernel.org; pablo@netfilter.org; osmocom-net-gprs@lists.osmocom.org
Subject: RE: [RFC PATCH net-next v4 4/6] gtp: Implement GTP echo response

Hi Harald,

quoted

-----Original Message-----
From: Harald Welte <redacted>
Sent: piątek, 11 lutego 2022 10:16
To: Drewek, Wojciech <redacted>
Cc: Marcin Szycik <redacted>; netdev@vger.kernel.org; michal.swiatkowski@linux.intel.com;
davem@davemloft.net; kuba@kernel.org; pablo@netfilter.org; osmocom-net-gprs@lists.osmocom.org
Subject: 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

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...

quoted

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.

quoted

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

I agree that second option is better so I'll start to implementing it.

I have one question. The new cmd should be allowed to send echo request
only to the peers stored in the kernel space (PDP contexts) or the userspace
daemon has its own list of peers and any request should be allowed to be send?

Regards,
Wojtek 

Regards,
Wojtek

quoted

--
- 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)