Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210626052152.2543526-1-mcchou@chromium.org> <CALWDO_V6y0sCVOGJjCfn7eqQ3RAc4NHqsFbXxRmGvnzGxU26ZQ@mail.gmail.com>
 <5350EBBD-7F81-448E-B96A-A1C09F8EC676@holtmann.org> <2206189.ElGaqSPkdT@ix>
In-Reply-To: <2206189.ElGaqSPkdT@ix>
From:   Alain Michaud <alainmichaud@google.com>
Date:   Fri, 23 Jul 2021 09:20:17 -0400
Message-ID: <CALWDO_UPexnNmFSf8i8ONkEfQknLqacgw8k4MQs9pejWnD99jQ@mail.gmail.com>
Subject: Re: [BlueZ PATCH v2 1/3] error: BR/EDR and LE connection failure reasons
To:     Szymon Janc <szymon.janc@codecoup.pl>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        Miao-chen Chou <mcchou@chromium.org>,
        Bluetooth Kernel Mailing List 
        <linux-bluetooth@vger.kernel.org>,
        Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
        Alain Michaud <alainm@chromium.org>,
        Howard Chung <howardchung@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jul 23, 2021 at 4:20 AM Szymon Janc <szymon.janc@codecoup.pl> wrote:
>
> Hi,
>
> On Friday, 23 July 2021 09:38:40 CEST Marcel Holtmann wrote:
>
> > >>>>> What is the intention to split BR/EDR and LE here. You do know
> > >>>>> up-front what connection type you are. Trying to figure out from the
> > >>>>> error code what connection you have been trying to establish is plain
> > >>>>> wrong.>>>>
> > >>>> In fact the up-front connection type is not necessarily known. In the
> > >>>> case of dual-mode devices, such as Bose QC35, a D-Bus client can issue
> > >>>> Connect(), and it depends on the timing of connection request (adv
> > >>>> usually arrive first compared to inquiry result), it can be either
> > >>>> BR/EDR or LE link being established. Another aspect of this is the
> > >>>> metrics collection, where knowing transport can be handy. For
> > >>>> instance, we can associate the certain error to particular use cases
> > >>>> at application layer, and that can help targeting the bottleneck to
> > >>>> tackle.
> > >>>
> > >>> Then we need to find a different way to convey the transport chosen.
> > >>> Doing this by error message is a bad idea.>>>
> > >>>>> The description is that you want to know exactly where the connection
> > >>>>> failed. And I think that can be established independent from the
> > >>>>> transport.>>>>
> > >>>> Indeed the intention is to know where it failed exactly. However, as
> > >>>> mentioned above, transport information is also an important piece of
> > >>>> information to know.
> > >>>
> > >>> We need to find a different way to inform about which transport failed
> > >>> (or better which was chosen in the first place).>
> > > I would love to hear your thoughts on an alternative.  Many of the
> > > Apis are transport agnostic (Connect/Pair may end up connecting to
> > > either available transports for dual mode devices), but yet the error
> > > that results from them are not.  Errors from one transport doesn't
> > > make sense for one and vice versa.  A platform wanting to leverage
> > > telemetry and metrics to drive ecosystem improvements would ultimately
> > > need to know the difference even if the applications may not need to
> > > care.
> >
> > and we might have made a mistake in the API design and should have given the
> > caller more control. We need to review the API design and see if things
> > have to change. Just glueing things on at the end makes me suspicious.
>
> Some (5, wow!) years back I've loosely proposed split for org.bluez.Device API
> that was meant to handle some of the dual mode devices issues we've been
> seeing [1] [2].
>
> We never got time to fully implement it (mostly due to hacking around device.c
> instead of properly splitting internal implementation into device_le.c and
> device_bredr.c) but got some very initial PoC running.
>
> With new interfaces old Device1 could be simply super-set of two for legacy
> applications purposes.
>
> Maybe such approach is worth re-considering?
>
>
> [1] https://marc.info/?l=linux-bluetooth&m=145710680912268&w=2
> [2] https://marc.info/?l=linux-bluetooth&m=145973293118003&w=2
Definitely worth reconsidering.  We've recently introduced a ConnectLE
Api as a stop gap measure for something very similar.  I'd love to see
the equivalent of a ConnectClassic / ConnectLE distinction.

However, I still believe the "Generic" Connect serves its purpose as
you alluded to above.  Even if it could be built using layers, I still
believe there is value from a telemetry POV to understand the errors
from the field better and there, the distinction between the specific
transport matter.  Just like today, I suspect many applications will
continue to use the generic "Connect" as to not replicate the logic it
ultimately implements for dealing with dual mode devices, yet
results/metrics would be important.

The team strives to improve interoperability at a large scale in the
ecosystem, I believe these data point distinctions are a critical
enabler to get better insights into the specific errors customers are
seeing.  A counter proposal that would be acceptable to you, achieves
the objectives and that the team can implement would be a nice next
step.

Thanks!
Alain
>
>
> --
> pozdrawiam
> Szymon Janc
>
>