Date:   Tue, 18 Dec 2018 20:29:09 +0100
From:   Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
To:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: Plans for meshd
Message-ID: <20181218192909.27htxh3glfgjmial@kynes>
Mail-Followup-To: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <CACXRGxyMGt1zecvRmgoa5uuSwy4H9UpSECM0tOuC+uXGmQoGNg@mail.gmail.com>
 <DEBB0CAA2616974FAE35E4B560B9A4375D8E02FE@ORSMSX101.amr.corp.intel.com>
 <20181218110838.ollsqils5ci7cq4v@scytale>
 <DEBB0CAA2616974FAE35E4B560B9A4375D8E0B35@ORSMSX101.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DEBB0CAA2616974FAE35E4B560B9A4375D8E0B35@ORSMSX101.amr.corp.intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 12/18, Gix, Brian wrote:
> Maybe we should start with what you actually need.
> * Do you need GATT support only for the Provisioning procedure?
Primarily, but not only this. As Danielle mentioned, there are cases
where we would like to "fall back" to GATT in order to exchange large
amounts of data with a selected node. This is going to happen only
occassionally, so it won't affect the "steady state" performance of a
mesh network. Spec even mentions that particular use case, via Node
Identity procedure.

> * or also as a GATT proxy Server?
No, at the moment we don't need GATT Proxy Server support in Linux,
althouth long-term I think it would be beneficial for bluez to have
this.

> * I do not think we should try to support Proxy Client *at all*.
Agreed.

> The Proxy Client assumes a single Node, which defeats the purpose of
> having a daemon at all.
>
> * Only a single node (or unprovisioned GATT server) can use GATT at a
> time.  The protocol does not allow for the multi-node architecture of
> the daemon.
I do not think this is true. The spec doesn't seem to put any
limitations on the Network PDUs you can exchange with the GATT Proxy
Server, so I think it is entirely possible to have multiple Mesh nodes
share a single GATT connection to a proxy.

Noone does that, though, because performance of such a setup would
probably be abysmal :) In the end, I don't consider this a "real" use
case.

> *  If we do try to put a GATT Proxy Server on a single controller
> implementation, we may need a special node that loops back data
> received from the Mesh to the Gatt Client.
Well, I was wondering if it would be feasible to implement another
flavour of mesh-io layer, that would talk to Bluetooth Daemon (possibly
via API extensions) instead of opening the hci user channel on its own.

For that to work, the main Bluetooth Daemon would need to expose D-Bus
signals to retrieve "raw" advertising indications, and a method to send
a single advertising packet.

Alternatively (and this is just me thinking out loud), maybe it would be
possible to dup() the HCI socket and pass it to the Mesh Daemon,
assuming it gets spawneby by fork()ing Bluetooth Daemon? Not sure if the
kernel interface allows such sheganigans.

> * We may want to make this a build-time option, because ADV handling
> will probably be affected whether an existing GATT connection is
> established or not, if it is possible that a GATT connection could be
> requested.
> 
> * This affects the times when we can use Randomized, ever changing BD
> ADDRs, and requires us to interleave connectable advertisements and
> "be connectable", which is not technically allowed with mesh network
> ADV packets.
In our experience, /just enabling/ Proxy Server on a node (thus making
it advertise with connectables) does not seem affect delivery rate of
mesh packets, at least not meaningfully (0.1%, maybe). The performance
drop is observable only after an actual connection is established, and
is in 10-20% range, if I recall correctly.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND