Enhancements to allow l2cap channel to use either AMP or BR/EDR

Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Inga Stotland]

AMP vs BR/EDR preference for L2CAP channel can be configured as 
command line argument using new option "-J". Possible values: 
                 "require_br_edr", 
                 "prefer_amp", 
                 "prefer_br_edr"
If no preference indicated, the default is set to require BR/EDR. 

Additionally, this option can be changed during  runtime when L2CAP 
connection is up by entering the following keys from standard input:   
         "a", "A" - prefer AMP;
         "b", "B" - prefer BR/EDR;
         "r", "R" - require BR/EDR
This allows dynamic L2CAP channel move between BR/EDR and AMP.


--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 1/4] Constants for L2CAP and AMP extensions

[Inga Stotland]

---
 lib/l2cap.h |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/lib/l2cap.h b/lib/l2cap.h
index e59cfdd..2f1084c 100644
--- a/lib/l2cap.h
+++ b/lib/l2cap.h
@@ -35,6 +35,8 @@ extern "C" {
 /* L2CAP defaults */
 #define L2CAP_DEFAULT_MTU	672
 #define L2CAP_DEFAULT_FLUSH_TO	0xFFFF
+#define L2CAP_DEFAULT_TX_WINDOW	63
+#define L2CAP_DEFAULT_MAX_TX	3
 
 /* L2CAP socket address */
 struct sockaddr_l2 {
@@ -44,6 +46,12 @@ struct sockaddr_l2 {
 	unsigned short	l2_cid;
 };
 
+/* L2CAP fixed channel CIDs */
+#define L2CAP_SIGNAL_CHAN_CID		0x0001
+#define L2CAP_CONNECTIONLESS_CID	0x0002
+#define L2CAP_AMP_MGR_CID		0x0003
+#define L2CAP_AMP_TEST_CID		0x003F
+
 /* L2CAP socket options */
 #define L2CAP_OPTIONS	0x01
 struct l2cap_options {
@@ -69,6 +77,12 @@ struct l2cap_conninfo {
 #define L2CAP_LM_TRUSTED	0x0008
 #define L2CAP_LM_RELIABLE	0x0010
 #define L2CAP_LM_SECURE		0x0020
+#define L2CAP_LM_FLUSHABLE	0x0040
+
+#define L2CAP_AMP	0x04
+#define L2CAP_AMP_REQUIRE_BR_EDR	0x01
+#define L2CAP_AMP_PREFER_AMP		0x02
+#define L2CAP_AMP_PREFER_BR_EDR	0x03
 
 /* L2CAP command codes */
 #define L2CAP_COMMAND_REJ	0x01
-- 
1.7.2

--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 2/4] Use defines for the default values of txwin_size and max_transmit.

[Inga Stotland]

---
 test/l2test.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/test/l2test.c b/test/l2test.c
index 0bb46f3..361f80c 100644
--- a/test/l2test.c
+++ b/test/l2test.c
@@ -76,10 +76,10 @@ static int omtu = 0;
 static int fcs = 0x01;
 
 /* Default Transmission Window */
-static int txwin_size = 63;
+static int txwin_size = L2CAP_DEFAULT_TX_WINDOW;
 
-/* Default Max Transmission */
-static int max_transmit = 3;
+/* Default Max Transmission (number of retries per packet) */
+static int max_transmit = L2CAP_DEFAULT_MAX_TX;
 
 /* Default data size */
 static long data_size = -1;
@@ -1073,8 +1073,8 @@ static void usage(void)
 		"\t[-D milliseconds] delay after sending num frames (default = 0)\n"
 		"\t[-X mode] select retransmission/flow-control mode\n"
 		"\t[-F fcs] use CRC16 check (default = 1)\n"
-		"\t[-Q num] Max Transmit value (default = 3)\n"
-		"\t[-Z size] Transmission Window size (default = 63)\n"
+		"\t[-Q num] Max Transmit value (default = %d)\n"
+		"\t[-Z size] Transmission Window size (default = %d)\n"
 		"\t[-R] reliable mode\n"
 		"\t[-G] use connectionless channel (datagram)\n"
 		"\t[-U] use sock stream\n"
@@ -1082,7 +1082,8 @@ static void usage(void)
 		"\t[-E] request encryption\n"
 		"\t[-S] secure connection\n"
 		"\t[-M] become master\n"
-		"\t[-T] enable timestamps\n");
+		"\t[-T] enable timestamps\n",
+		L2CAP_DEFAULT_MAX_TX, L2CAP_DEFAULT_TX_WINDOW);
 }
 
 int main(int argc, char *argv[])
-- 
1.7.2

--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 3/4] Added command argument "-J" to indicate preference of using AMP vs BR/EDR.

[Inga Stotland]

Possible values: "require_br_edr", "prefer_amp", "prefer_br_edr"
---
 test/l2test.c |   34 +++++++++++++++++++++++++++++++++-
 1 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/test/l2test.c b/test/l2test.c
index 361f80c..377c12e 100644
--- a/test/l2test.c
+++ b/test/l2test.c
@@ -81,6 +81,9 @@ static int txwin_size = L2CAP_DEFAULT_TX_WINDOW;
 /* Default Max Transmission (number of retries per packet) */
 static int max_transmit = L2CAP_DEFAULT_MAX_TX;
 
+/* Default AMP preference */
+static int amp_pref = L2CAP_AMP_REQUIRE_BR_EDR;
+
 /* Default data size */
 static long data_size = -1;
 static long buffer_size = 2048;
@@ -295,6 +298,14 @@ static int do_connect(char *svr)
 		goto error;
 	}
 
+	/* Set AMP preference */
+	if ((rfcmode == L2CAP_MODE_ERTM || rfcmode == L2CAP_MODE_STREAMING) &&
+		setsockopt(sk, SOL_L2CAP, L2CAP_AMP, &amp_pref, sizeof(amp_pref)) < 0) {
+		syslog(LOG_ERR, "Can't set L2CAP AMP preference: %s (%d)",
+							strerror(errno), errno);
+		goto error;
+	}
+
 	/* Get current options */
 	memset(&opts, 0, sizeof(opts));
 	optlen = sizeof(opts);
@@ -458,6 +469,14 @@ static void do_listen(void (*handler)(int sk))
 		/* Child */
 		close(sk);
 
+		/* Set AMP preference */
+		if ((rfcmode == L2CAP_MODE_ERTM || rfcmode == L2CAP_MODE_STREAMING) &&
+			setsockopt(nsk, SOL_L2CAP, L2CAP_AMP, &amp_pref, sizeof(amp_pref)) < 0) {
+			syslog(LOG_ERR, "Can't set L2CAP AMP preference: %s (%d)",
+				   strerror(errno), errno);
+			goto error;
+		}
+
 		/* Get current options */
 		memset(&opts, 0, sizeof(opts));
 		optlen = sizeof(opts);
@@ -1075,6 +1094,8 @@ static void usage(void)
 		"\t[-F fcs] use CRC16 check (default = 1)\n"
 		"\t[-Q num] Max Transmit value (default = %d)\n"
 		"\t[-Z size] Transmission Window size (default = %d)\n"
+		"\t[-J amp] declare amp preference\n"
+		"\t         (require_br_edr, prefer_amp, prefer_br_edr)\n"
 		"\t[-R] reliable mode\n"
 		"\t[-G] use connectionless channel (datagram)\n"
 		"\t[-U] use sock stream\n"
@@ -1093,7 +1114,7 @@ int main(int argc, char *argv[])
 
 	bacpy(&bdaddr, BDADDR_ANY);
 
-	while ((opt=getopt(argc,argv,"rdscuwmntqxyzpb:i:P:I:O:B:N:L:W:C:D:X:F:Q:Z:RUGAESMT")) != EOF) {
+	while ((opt=getopt(argc,argv,"rdscuwmntqxyzpb:i:P:I:O:B:N:L:W:C:D:X:F:Q:Z:J:RUGAESMT")) != EOF) {
 		switch(opt) {
 		case 'r':
 			mode = RECV;
@@ -1217,6 +1238,17 @@ int main(int argc, char *argv[])
 			fcs = atoi(optarg);
 			break;
 
+		case 'J':
+			if (strcasecmp(optarg, "require_br_edr") == 0)
+				amp_pref = L2CAP_AMP_REQUIRE_BR_EDR;
+			else if (strcasecmp(optarg, "prefer_amp") == 0)
+				amp_pref = L2CAP_AMP_PREFER_AMP;
+			else if (strcasecmp(optarg, "prefer_br_edr") == 0)
+				amp_pref = L2CAP_AMP_PREFER_BR_EDR;
+			else
+				perror("Bad AMP preference");
+			break;
+
 		case 'R':
 			reliable = 1;
 			break;
-- 
1.7.2

--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCH 3/4] Added command argument "-J" to indicate preference of using AMP vs BR/EDR.

[Gustavo F. Padovan]

Hi Inga,

* Inga Stotland <ingas@codeaurora.org> [2010-07-30 11:30:25 -0700]:

> Possible values: "require_br_edr", "prefer_amp", "prefer_br_edr"
> ---
>  test/l2test.c |   34 +++++++++++++++++++++++++++++++++-
>  1 files changed, 33 insertions(+), 1 deletions(-)
	
I would prefer to review and merge the kernel bits first and then go to
the userspace stuff. Doing that we'll have more sure that the socket
options won't change.

-- 
Gustavo F. Padovan
http://padovan.org

Re: [PATCH 3/4] Added command argument "-J" to indicate preference of using AMP vs BR/EDR.

[ingas]

Hi Gustavo,

> Hi Inga,
>
> * Inga Stotland <ingas@codeaurora.org> [2010-07-30 11:30:25 -0700]:
>
>> Possible values: "require_br_edr", "prefer_amp", "prefer_br_edr"
>> ---
>>  test/l2test.c |   34 +++++++++++++++++++++++++++++++++-
>>  1 files changed, 33 insertions(+), 1 deletions(-)
>
> I would prefer to review and merge the kernel bits first and then go to
> the userspace stuff. Doing that we'll have more sure that the socket
> options won't change.
>
> --
> Gustavo F. Padovan
> http://padovan.org
> --

I don't disagree with you. The kernel bits are coming this week. we will
retest l2test again when kernel stuff is upstreamed. This is just a sample
of how we envision the socket options to control the use of AMP...

And anyway, it takes me up to five iterations to get the style right :)

Regards,

Inga


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH 4/4] Allow changing AMP vs BR/EDR preference from stdin when connection is up.

[Inga Stotland]

Use the following keys:

"a", "A" - prefer AMP;
"b", "B" - prefer BR/EDR;
"r", "R" - require BR/EDR
---
 test/l2test.c |   87 +++++++++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 76 insertions(+), 11 deletions(-)

diff --git a/test/l2test.c b/test/l2test.c
index 377c12e..1f627a7 100644
--- a/test/l2test.c
+++ b/test/l2test.c
@@ -191,6 +191,46 @@ static void hexdump(unsigned char *s, unsigned long l)
 	}
 }
 
+static void do_keys(int sk)
+{
+	struct pollfd p;
+	int len;
+	char c;
+	int old_amp_pref = amp_pref;
+
+	p.fd = 0;
+	p.events = POLLIN;
+
+	if (poll(&p, 1, 0)) {
+		len = read(0, &c, 1);
+		if (len < 0)
+			return;
+
+		switch (c) {
+		case 'A':
+		case 'a':
+			amp_pref = L2CAP_AMP_PREFER_AMP;
+			break;
+		case 'B':
+		case 'b':
+			amp_pref = L2CAP_AMP_PREFER_BR_EDR;
+			break;
+		case 'R':
+		case 'r':
+			amp_pref = L2CAP_AMP_REQUIRE_BR_EDR;
+			break;
+		default:
+			return;
+		}
+
+		setsockopt(sk, SOL_L2CAP, L2CAP_AMP, &amp_pref, sizeof(amp_pref));
+		syslog(LOG_INFO, "AMP preference updated to %d (previously %d)",
+			amp_pref, old_amp_pref);
+	}
+
+	return;
+}
+
 static int do_connect(char *svr)
 {
 	struct sockaddr_l2 addr;
@@ -584,11 +624,17 @@ static void dump_mode(int sk)
 		fd_set rset;
 
 		FD_ZERO(&rset);
+		FD_SET(0, &rset);
 		FD_SET(sk, &rset);
 
 		if (select(sk + 1, &rset, NULL, NULL, NULL) < 0)
 			return;
 
+		if (FD_ISSET(0, &rset)) {
+			do_keys(sk);
+			continue;
+		}
+
 		if (!FD_ISSET(sk, &rset))
 			continue;
 
@@ -620,7 +666,7 @@ static void dump_mode(int sk)
 static void recv_mode(int sk)
 {
 	struct timeval tv_beg, tv_end, tv_diff;
-	struct pollfd p;
+	struct pollfd p[2];
 	char ts[30];
 	long total;
 	uint32_t seq;
@@ -643,8 +689,11 @@ static void recv_mode(int sk)
 
 	memset(ts, 0, sizeof(ts));
 
-	p.fd = sk;
-	p.events = POLLIN | POLLERR | POLLHUP;
+	p[0].fd = sk;
+	p[0].events = POLLIN | POLLERR | POLLHUP;
+
+	p[1].fd = 0;
+	p[1].events = POLLIN;
 
 	seq = 0;
 	while (1) {
@@ -655,13 +704,19 @@ static void recv_mode(int sk)
 			uint16_t l;
 			int i;
 
-			p.revents = 0;
-			if (poll(&p, 1, -1) <= 0)
+			p[0].revents = 0;
+			p[1].revents = 0;
+			if (poll(p, 2, -1) <= 0)
 				return;
 
-			if (p.revents & (POLLERR | POLLHUP))
+			if (p[0].revents & (POLLERR | POLLHUP))
 				return;
 
+			if (p[1].revents & POLLIN) {
+				do_keys(sk);
+				continue;
+			}
+
 			len = recv(sk, buf, data_size, 0);
 			if (len < 0) {
 				if (reliable && (errno == ECOMM)) {
@@ -780,6 +835,8 @@ static void do_send(int sk)
 
 			sent += len;
 			size -= len;
+
+			do_keys(sk);
 		}
 
 		if (num_frames && delay && count && !(seq % count))
@@ -831,19 +888,27 @@ static void reconnect_mode(char *svr)
 
 static void connect_mode(char *svr)
 {
-	struct pollfd p;
+	struct pollfd p[2];
 	int sk;
 
 	if ((sk = do_connect(svr)) < 0)
 		exit(1);
 
-	p.fd = sk;
-	p.events = POLLERR | POLLHUP;
+	p[0].fd = sk;
+	p[0].events = POLLERR | POLLHUP;
+
+	p[1].fd = 0;
+	p[1].events = POLLIN;
 
 	while (1) {
-		p.revents = 0;
-		if (poll(&p, 1, 500))
+		p[0].revents = 0;
+		p[1].revents = 0;
+		if (poll(p, 2, 500) < 0)
+			break;
+		if (p[0].revents & (POLLERR | POLLHUP))
 			break;
+		if (p[1].revents & POLLIN)
+			do_keys(sk);
 	}
 
 	syslog(LOG_INFO, "Disconnected");
-- 
1.7.2

--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[David Vrabel]

Inga Stotland wrote:
> AMP vs BR/EDR preference for L2CAP channel can be configured as 
> command line argument using new option "-J". Possible values: 
>                  "require_br_edr", 
>                  "prefer_amp", 
>                  "prefer_br_edr"
> If no preference indicated, the default is set to require BR/EDR. 

I think an explicit channel move command and a channel move complete
event are what many applications/profiles will need to be able to use an
AMP effectively.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[tmonahan]

Hi, David,

>> AMP vs BR/EDR preference for L2CAP channel can be configured as command
line argument using new option "-J". Possible values:
>>                  "require_br_edr",
>>                  "prefer_amp",
>>                  "prefer_br_edr"
>> If no preference indicated, the default is set to require BR/EDR.
>
> I think an explicit channel move command and a channel move complete
event are what many applications/profiles will need to be able to use an
AMP effectively.

A future AMP policy setting of "manual" could certainly give each
application the freedom to move an l2cap channel at will, after applying
its own decision making process. However, with that freedom comes the
responsibility of processing the AMP related events and initiating the AMP
commands to make the decision. For example, the application needs to know
if AMP controllers are available both locally and remotely, which in turn
requires initiating the AMP discovery process and looking over the
available local HCI devices; a loss of the physical link event means the
application must move the link back to BR/EDR, etc. All of the additional
machinery to accomplish that could indeed be exposed for use by
applications. I think such an approach, if really needed, would not
conflict with these proposed policies that hide all of that within the
kernel.

To illustrate how these policies simplify applications, consider OBEX. An
OBEX server application would choose "prefer_br_edr", thus leaving the
remote OBEX client to decide and initiate the channel move to an AMP, and
thus granting advance permission to the kernel for the move to take place.
The OBEX client could examine the size of an upcoming transfer and choose
"prefer_amp", thereby instructing the kernel to initiate the move to an
AMP if all local and remote conditions allow it. Thus, the OBEX client and
server applications make simplistic decisions to set up AMP, and can focus
on moving data over the l2cap channel, leaving the management of what
medium the data flows over up to the kernel, who keeps it transparent. In
this way, work to make an existing profile "AMP aware" is also minimal.

In the discussion with Marcel regarding our AMP proposal in March ("RFC:
QuIC's AMP + eL2CAP Technical Plans"), where we had listed these AMP
control policies, he seemed to indicate that these policies would
automatically trigger AMP discovery within the kernel, which it will. As
he said, "Less options are less confusing for users" (apologies in advance
if I misinterpreted his answer).

Best regards,
Tim Monahan-Mitchell

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Marcel Holtmann]

Hi Tim,

please fix your mail client to NOT break threading.

> >> AMP vs BR/EDR preference for L2CAP channel can be configured as command
> line argument using new option "-J". Possible values:
> >>                  "require_br_edr",
> >>                  "prefer_amp",
> >>                  "prefer_br_edr"
> >> If no preference indicated, the default is set to require BR/EDR.
> >
> > I think an explicit channel move command and a channel move complete
> event are what many applications/profiles will need to be able to use an
> AMP effectively.
> 
> A future AMP policy setting of "manual" could certainly give each
> application the freedom to move an l2cap channel at will, after applying
> its own decision making process. However, with that freedom comes the
> responsibility of processing the AMP related events and initiating the AMP
> commands to make the decision. For example, the application needs to know
> if AMP controllers are available both locally and remotely, which in turn
> requires initiating the AMP discovery process and looking over the
> available local HCI devices; a loss of the physical link event means the
> application must move the link back to BR/EDR, etc. All of the additional
> machinery to accomplish that could indeed be exposed for use by
> applications. I think such an approach, if really needed, would not
> conflict with these proposed policies that hide all of that within the
> kernel.
> 
> To illustrate how these policies simplify applications, consider OBEX. An
> OBEX server application would choose "prefer_br_edr", thus leaving the
> remote OBEX client to decide and initiate the channel move to an AMP, and
> thus granting advance permission to the kernel for the move to take place.
> The OBEX client could examine the size of an upcoming transfer and choose
> "prefer_amp", thereby instructing the kernel to initiate the move to an
> AMP if all local and remote conditions allow it. Thus, the OBEX client and
> server applications make simplistic decisions to set up AMP, and can focus
> on moving data over the l2cap channel, leaving the management of what
> medium the data flows over up to the kernel, who keeps it transparent. In
> this way, work to make an existing profile "AMP aware" is also minimal.
> 
> In the discussion with Marcel regarding our AMP proposal in March ("RFC:
> QuIC's AMP + eL2CAP Technical Plans"), where we had listed these AMP
> control policies, he seemed to indicate that these policies would
> automatically trigger AMP discovery within the kernel, which it will. As
> he said, "Less options are less confusing for users" (apologies in advance
> if I misinterpreted his answer).

my current approach here is still that we wanna do this automatically in
the background for the profiles. I think at most the profiles should
just provide a threshold for either a) staying on BR/EDR or b) moving
over to AMP.

I know that the Bluetooth SIG tries to define such policies as part of
the profiles (like FTP for example), but I think this makes sense. I
doubt the real usage of making this manual. A profile/application should
just give its preference or intent and then we try to accommodate them
as best as possible.

The other problem here is also that besides whatever the profiles wants,
it might happen that the WiFi policy is stronger and only allows using
the WiFi device as WiFi or as AMP. And if WiFi wins, then we have to rip
the AMP out of the system. At that point whatever the Bluetooth profiles
wanted is pointless since the AMP controller is gone anyway.

That said, nothing stops us from allowing to make our AMP polices
dynamic and allow the application to change it threshold during
lifetime. For example it starts out as BR/EDR only and then during the
usage of the link it decides that now AMP preferred would make sense. In
that sense you would have manual switching to some level.

Regards

Marcel

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Kevin Hayes]

SGkgTWFyY2VsLA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGlu
dXgtYmx1ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWJsdWV0b290
aC0NCj4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgTWFyY2VsIEhvbHRtYW5u
DQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDAyLCAyMDEwIDExOjUzIEFNDQo+IFRvOiB0bW9uYWhh
bkBjb2RlYXVyb3JhLm9yZw0KPiBTdWJqZWN0OiBSZTogRW5oYW5jZW1lbnRzIHRvIGFsbG93IGwy
Y2FwIGNoYW5uZWwgdG8gdXNlIGVpdGhlciBBTVAgb3INCj4gQlIvRURSDQo+IA0KPiBIaSBUaW0s
DQo+IA0KPiBwbGVhc2UgZml4IHlvdXIgbWFpbCBjbGllbnQgdG8gTk9UIGJyZWFrIHRocmVhZGlu
Zy4NCj4gDQo+ID4gPj4gQU1QIHZzIEJSL0VEUiBwcmVmZXJlbmNlIGZvciBMMkNBUCBjaGFubmVs
IGNhbiBiZSBjb25maWd1cmVkIGFzDQo+IGNvbW1hbmQNCj4gPiBsaW5lIGFyZ3VtZW50IHVzaW5n
IG5ldyBvcHRpb24gIi1KIi4gUG9zc2libGUgdmFsdWVzOg0KPiA+ID4+ICAgICAgICAgICAgICAg
ICAgInJlcXVpcmVfYnJfZWRyIiwNCj4gPiA+PiAgICAgICAgICAgICAgICAgICJwcmVmZXJfYW1w
IiwNCj4gPiA+PiAgICAgICAgICAgICAgICAgICJwcmVmZXJfYnJfZWRyIg0KPiA+ID4+IElmIG5v
IHByZWZlcmVuY2UgaW5kaWNhdGVkLCB0aGUgZGVmYXVsdCBpcyBzZXQgdG8gcmVxdWlyZSBCUi9F
RFIuDQo+ID4gPg0KPiA+ID4gSSB0aGluayBhbiBleHBsaWNpdCBjaGFubmVsIG1vdmUgY29tbWFu
ZCBhbmQgYSBjaGFubmVsIG1vdmUNCj4gY29tcGxldGUNCj4gPiBldmVudCBhcmUgd2hhdCBtYW55
IGFwcGxpY2F0aW9ucy9wcm9maWxlcyB3aWxsIG5lZWQgdG8gYmUgYWJsZSB0byB1c2UNCj4gYW4N
Cj4gPiBBTVAgZWZmZWN0aXZlbHkuDQo+ID4NCj4gPiBBIGZ1dHVyZSBBTVAgcG9saWN5IHNldHRp
bmcgb2YgIm1hbnVhbCIgY291bGQgY2VydGFpbmx5IGdpdmUgZWFjaA0KPiA+IGFwcGxpY2F0aW9u
IHRoZSBmcmVlZG9tIHRvIG1vdmUgYW4gbDJjYXAgY2hhbm5lbCBhdCB3aWxsLCBhZnRlcg0KPiBh
cHBseWluZw0KPiA+IGl0cyBvd24gZGVjaXNpb24gbWFraW5nIHByb2Nlc3MuIEhvd2V2ZXIsIHdp
dGggdGhhdCBmcmVlZG9tIGNvbWVzIHRoZQ0KPiA+IHJlc3BvbnNpYmlsaXR5IG9mIHByb2Nlc3Np
bmcgdGhlIEFNUCByZWxhdGVkIGV2ZW50cyBhbmQgaW5pdGlhdGluZw0KPiB0aGUgQU1QDQo+ID4g
Y29tbWFuZHMgdG8gbWFrZSB0aGUgZGVjaXNpb24uIEZvciBleGFtcGxlLCB0aGUgYXBwbGljYXRp
b24gbmVlZHMgdG8NCj4ga25vdw0KPiA+IGlmIEFNUCBjb250cm9sbGVycyBhcmUgYXZhaWxhYmxl
IGJvdGggbG9jYWxseSBhbmQgcmVtb3RlbHksIHdoaWNoIGluDQo+IHR1cm4NCj4gPiByZXF1aXJl
cyBpbml0aWF0aW5nIHRoZSBBTVAgZGlzY292ZXJ5IHByb2Nlc3MgYW5kIGxvb2tpbmcgb3ZlciB0
aGUNCj4gPiBhdmFpbGFibGUgbG9jYWwgSENJIGRldmljZXM7IGEgbG9zcyBvZiB0aGUgcGh5c2lj
YWwgbGluayBldmVudCBtZWFucw0KPiB0aGUNCj4gPiBhcHBsaWNhdGlvbiBtdXN0IG1vdmUgdGhl
IGxpbmsgYmFjayB0byBCUi9FRFIsIGV0Yy4gQWxsIG9mIHRoZQ0KPiBhZGRpdGlvbmFsDQo+ID4g
bWFjaGluZXJ5IHRvIGFjY29tcGxpc2ggdGhhdCBjb3VsZCBpbmRlZWQgYmUgZXhwb3NlZCBmb3Ig
dXNlIGJ5DQo+ID4gYXBwbGljYXRpb25zLiBJIHRoaW5rIHN1Y2ggYW4gYXBwcm9hY2gsIGlmIHJl
YWxseSBuZWVkZWQsIHdvdWxkIG5vdA0KPiA+IGNvbmZsaWN0IHdpdGggdGhlc2UgcHJvcG9zZWQg
cG9saWNpZXMgdGhhdCBoaWRlIGFsbCBvZiB0aGF0IHdpdGhpbg0KPiB0aGUNCj4gPiBrZXJuZWwu
DQo+ID4NCj4gPiBUbyBpbGx1c3RyYXRlIGhvdyB0aGVzZSBwb2xpY2llcyBzaW1wbGlmeSBhcHBs
aWNhdGlvbnMsIGNvbnNpZGVyDQo+IE9CRVguIEFuDQo+ID4gT0JFWCBzZXJ2ZXIgYXBwbGljYXRp
b24gd291bGQgY2hvb3NlICJwcmVmZXJfYnJfZWRyIiwgdGh1cyBsZWF2aW5nDQo+IHRoZQ0KPiA+
IHJlbW90ZSBPQkVYIGNsaWVudCB0byBkZWNpZGUgYW5kIGluaXRpYXRlIHRoZSBjaGFubmVsIG1v
dmUgdG8gYW4gQU1QLA0KPiBhbmQNCj4gPiB0aHVzIGdyYW50aW5nIGFkdmFuY2UgcGVybWlzc2lv
biB0byB0aGUga2VybmVsIGZvciB0aGUgbW92ZSB0byB0YWtlDQo+IHBsYWNlLg0KPiA+IFRoZSBP
QkVYIGNsaWVudCBjb3VsZCBleGFtaW5lIHRoZSBzaXplIG9mIGFuIHVwY29taW5nIHRyYW5zZmVy
IGFuZA0KPiBjaG9vc2UNCj4gPiAicHJlZmVyX2FtcCIsIHRoZXJlYnkgaW5zdHJ1Y3RpbmcgdGhl
IGtlcm5lbCB0byBpbml0aWF0ZSB0aGUgbW92ZSB0bw0KPiBhbg0KPiA+IEFNUCBpZiBhbGwgbG9j
YWwgYW5kIHJlbW90ZSBjb25kaXRpb25zIGFsbG93IGl0LiBUaHVzLCB0aGUgT0JFWA0KPiBjbGll
bnQgYW5kDQo+ID4gc2VydmVyIGFwcGxpY2F0aW9ucyBtYWtlIHNpbXBsaXN0aWMgZGVjaXNpb25z
IHRvIHNldCB1cCBBTVAsIGFuZCBjYW4NCj4gZm9jdXMNCj4gPiBvbiBtb3ZpbmcgZGF0YSBvdmVy
IHRoZSBsMmNhcCBjaGFubmVsLCBsZWF2aW5nIHRoZSBtYW5hZ2VtZW50IG9mIHdoYXQNCj4gPiBt
ZWRpdW0gdGhlIGRhdGEgZmxvd3Mgb3ZlciB1cCB0byB0aGUga2VybmVsLCB3aG8ga2VlcHMgaXQN
Cj4gdHJhbnNwYXJlbnQuIEluDQo+ID4gdGhpcyB3YXksIHdvcmsgdG8gbWFrZSBhbiBleGlzdGlu
ZyBwcm9maWxlICJBTVAgYXdhcmUiIGlzIGFsc28NCj4gbWluaW1hbC4NCj4gPg0KPiA+IEluIHRo
ZSBkaXNjdXNzaW9uIHdpdGggTWFyY2VsIHJlZ2FyZGluZyBvdXIgQU1QIHByb3Bvc2FsIGluIE1h
cmNoDQo+ICgiUkZDOg0KPiA+IFF1SUMncyBBTVAgKyBlTDJDQVAgVGVjaG5pY2FsIFBsYW5zIiks
IHdoZXJlIHdlIGhhZCBsaXN0ZWQgdGhlc2UgQU1QDQo+ID4gY29udHJvbCBwb2xpY2llcywgaGUg
c2VlbWVkIHRvIGluZGljYXRlIHRoYXQgdGhlc2UgcG9saWNpZXMgd291bGQNCj4gPiBhdXRvbWF0
aWNhbGx5IHRyaWdnZXIgQU1QIGRpc2NvdmVyeSB3aXRoaW4gdGhlIGtlcm5lbCwgd2hpY2ggaXQg
d2lsbC4NCj4gQXMNCj4gPiBoZSBzYWlkLCAiTGVzcyBvcHRpb25zIGFyZSBsZXNzIGNvbmZ1c2lu
ZyBmb3IgdXNlcnMiIChhcG9sb2dpZXMgaW4NCj4gYWR2YW5jZQ0KPiA+IGlmIEkgbWlzaW50ZXJw
cmV0ZWQgaGlzIGFuc3dlcikuDQo+IA0KPiBteSBjdXJyZW50IGFwcHJvYWNoIGhlcmUgaXMgc3Rp
bGwgdGhhdCB3ZSB3YW5uYSBkbyB0aGlzIGF1dG9tYXRpY2FsbHkNCj4gaW4NCj4gdGhlIGJhY2tn
cm91bmQgZm9yIHRoZSBwcm9maWxlcy4gSSB0aGluayBhdCBtb3N0IHRoZSBwcm9maWxlcyBzaG91
bGQNCj4ganVzdCBwcm92aWRlIGEgdGhyZXNob2xkIGZvciBlaXRoZXIgYSkgc3RheWluZyBvbiBC
Ui9FRFIgb3IgYikgbW92aW5nDQo+IG92ZXIgdG8gQU1QLg0KPiANCj4gSSBrbm93IHRoYXQgdGhl
IEJsdWV0b290aCBTSUcgdHJpZXMgdG8gZGVmaW5lIHN1Y2ggcG9saWNpZXMgYXMgcGFydCBvZg0K
PiB0aGUgcHJvZmlsZXMgKGxpa2UgRlRQIGZvciBleGFtcGxlKSwgYnV0IEkgdGhpbmsgdGhpcyBt
YWtlcyBzZW5zZS4gSQ0KPiBkb3VidCB0aGUgcmVhbCB1c2FnZSBvZiBtYWtpbmcgdGhpcyBtYW51
YWwuIEEgcHJvZmlsZS9hcHBsaWNhdGlvbg0KPiBzaG91bGQNCj4ganVzdCBnaXZlIGl0cyBwcmVm
ZXJlbmNlIG9yIGludGVudCBhbmQgdGhlbiB3ZSB0cnkgdG8gYWNjb21tb2RhdGUgdGhlbQ0KPiBh
cyBiZXN0IGFzIHBvc3NpYmxlLg0KDQpBZ3JlZSB0aGF0IGl0IHNob3VsZCBiZSBkb25lICJpbiBi
YWNrZ3JvdW5kIiBhbmQgdGhhdCBhIHNpemUgdGhyZXNob2xkIHdvdWxkIGJlIHVzZWZ1bC4gIEJ1
dCB3aG8gZXZhbHVhdGVzIHRoYXQgdGhyZXNob2xkPyAgVGhlIGJsdWV6IGtlcm5lbCBjb21wb25l
bnRzLCB3aGljaCBlc3NlbnRpYWxseSBpbXBsZW1lbnQgYSB0cmFuc3BvcnQgZHJpdmVyLCBzaG91
bGQgbm90IGJlIGV4YW1pbmluZyBvYmplY3RzIChmaWxlcywgcGhvbmVib29rcywgZXRjKSBzaXpl
IHRvIHNlZSBpZiB0aGlzIHRocmVzaG9sZCBpcyBtZXQuICBUaGVyZWZvcmUsIGl0IHdvdWxkIHNl
ZW0gVGltJ3Mgc3VnZ2VzdGlvbiBvZiBoYXZpbmcgdGhlIHByb2ZpbGUgc2VuZCBhICdwcmVmZXJf
YW1wJyBiaXQgd291bGQgYmUgdXNlZnVsLCByaWdodD8NCg0KPiANCj4gVGhlIG90aGVyIHByb2Js
ZW0gaGVyZSBpcyBhbHNvIHRoYXQgYmVzaWRlcyB3aGF0ZXZlciB0aGUgcHJvZmlsZXMNCj4gd2Fu
dHMsDQo+IGl0IG1pZ2h0IGhhcHBlbiB0aGF0IHRoZSBXaUZpIHBvbGljeSBpcyBzdHJvbmdlciBh
bmQgb25seSBhbGxvd3MgdXNpbmcNCj4gdGhlIFdpRmkgZGV2aWNlIGFzIFdpRmkgb3IgYXMgQU1Q
LiBBbmQgaWYgV2lGaSB3aW5zLCB0aGVuIHdlIGhhdmUgdG8NCj4gcmlwDQo+IHRoZSBBTVAgb3V0
IG9mIHRoZSBzeXN0ZW0uIEF0IHRoYXQgcG9pbnQgd2hhdGV2ZXIgdGhlIEJsdWV0b290aA0KPiBw
cm9maWxlcw0KPiB3YW50ZWQgaXMgcG9pbnRsZXNzIHNpbmNlIHRoZSBBTVAgY29udHJvbGxlciBp
cyBnb25lIGFueXdheS4NCg0KV2VsbCwgSSB0aGluayB0aGlzIGlzIGJlc3QgbWFuYWdlZCBieSBo
YXZpbmcgdGhlIFBBTCBhbm5vdW5jZSBpdHMgYXZhaWxhYmlsaXR5IChhbmQgdW5hdmFpbGFiaWxp
dHkpIHRvIEEyTVAsIHVzaW5nIHRoZSBzcGVjJ3MgSENJIGV2ZW50cyBmb3IgdGhpcyBwdXJwb3Nl
LiAgQTJNUCBjYW4gdGhlbiBiZSB0aGUgYWdlbnQgdG8gbW92ZSB0aGUgY2hhbm5lbCB0byBBTVAg
b3Igbm90LCBhY2NvcmRpbmdseS4gIEZvciBleGFtcGxlLCBpdCBtaWdodCBiZSB0aGF0IHRoZSA4
MDIuMTEgZGV2aWNlIGlzIGJlaW5nIHVzZWQgZm9yIGFuIGluZnJhc3RydWN0dXJlIGxpbmssIGFu
ZCB0aGVuIHRoYXQgbGluayBnb2VzIGF3YXkuICBUaGUgUEFMIHdvdWxkIHRoZW4gYW5ub3VuY2Ug
aXRzIGF2YWlsYWJpbGl0eSB0byB0aGUgQlQgc3RhY2sgKEEyTVApLCBhbmQgQTJNUCB3b3VsZCB0
aGVuIG1vdmUgdGhlIGNoYW5uZWwgdG8gQU1QLg0KDQo+IA0KPiBUaGF0IHNhaWQsIG5vdGhpbmcg
c3RvcHMgdXMgZnJvbSBhbGxvd2luZyB0byBtYWtlIG91ciBBTVAgcG9saWNlcw0KPiBkeW5hbWlj
IGFuZCBhbGxvdyB0aGUgYXBwbGljYXRpb24gdG8gY2hhbmdlIGl0IHRocmVzaG9sZCBkdXJpbmcN
Cj4gbGlmZXRpbWUuIEZvciBleGFtcGxlIGl0IHN0YXJ0cyBvdXQgYXMgQlIvRURSIG9ubHkgYW5k
IHRoZW4gZHVyaW5nIHRoZQ0KPiB1c2FnZSBvZiB0aGUgbGluayBpdCBkZWNpZGVzIHRoYXQgbm93
IEFNUCBwcmVmZXJyZWQgd291bGQgbWFrZSBzZW5zZS4NCj4gSW4NCj4gdGhhdCBzZW5zZSB5b3Ug
d291bGQgaGF2ZSBtYW51YWwgc3dpdGNoaW5nIHRvIHNvbWUgbGV2ZWwuDQoNClRoZSBvbmx5IHVz
ZSBjYXNlIEkgc2VlIGZvciBtYW51YWwgc3dpdGNoaW5nIGlzIGRlYnVnZ2luZy4NCg0KCUsrKw0K

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Marcel Holtmann]

Hi Kevin,

> > please fix your mail client to NOT break threading.
> > 
> > > >> AMP vs BR/EDR preference for L2CAP channel can be configured as
> > command
> > > line argument using new option "-J". Possible values:
> > > >>                  "require_br_edr",
> > > >>                  "prefer_amp",
> > > >>                  "prefer_br_edr"
> > > >> If no preference indicated, the default is set to require BR/EDR.
> > > >
> > > > I think an explicit channel move command and a channel move
> > complete
> > > event are what many applications/profiles will need to be able to use
> > an
> > > AMP effectively.
> > >
> > > A future AMP policy setting of "manual" could certainly give each
> > > application the freedom to move an l2cap channel at will, after
> > applying
> > > its own decision making process. However, with that freedom comes the
> > > responsibility of processing the AMP related events and initiating
> > the AMP
> > > commands to make the decision. For example, the application needs to
> > know
> > > if AMP controllers are available both locally and remotely, which in
> > turn
> > > requires initiating the AMP discovery process and looking over the
> > > available local HCI devices; a loss of the physical link event means
> > the
> > > application must move the link back to BR/EDR, etc. All of the
> > additional
> > > machinery to accomplish that could indeed be exposed for use by
> > > applications. I think such an approach, if really needed, would not
> > > conflict with these proposed policies that hide all of that within
> > the
> > > kernel.
> > >
> > > To illustrate how these policies simplify applications, consider
> > OBEX. An
> > > OBEX server application would choose "prefer_br_edr", thus leaving
> > the
> > > remote OBEX client to decide and initiate the channel move to an AMP,
> > and
> > > thus granting advance permission to the kernel for the move to take
> > place.
> > > The OBEX client could examine the size of an upcoming transfer and
> > choose
> > > "prefer_amp", thereby instructing the kernel to initiate the move to
> > an
> > > AMP if all local and remote conditions allow it. Thus, the OBEX
> > client and
> > > server applications make simplistic decisions to set up AMP, and can
> > focus
> > > on moving data over the l2cap channel, leaving the management of what
> > > medium the data flows over up to the kernel, who keeps it
> > transparent. In
> > > this way, work to make an existing profile "AMP aware" is also
> > minimal.
> > >
> > > In the discussion with Marcel regarding our AMP proposal in March
> > ("RFC:
> > > QuIC's AMP + eL2CAP Technical Plans"), where we had listed these AMP
> > > control policies, he seemed to indicate that these policies would
> > > automatically trigger AMP discovery within the kernel, which it will.
> > As
> > > he said, "Less options are less confusing for users" (apologies in
> > advance
> > > if I misinterpreted his answer).
> > 
> > my current approach here is still that we wanna do this automatically
> > in
> > the background for the profiles. I think at most the profiles should
> > just provide a threshold for either a) staying on BR/EDR or b) moving
> > over to AMP.
> > 
> > I know that the Bluetooth SIG tries to define such policies as part of
> > the profiles (like FTP for example), but I think this makes sense. I
> > doubt the real usage of making this manual. A profile/application
> > should
> > just give its preference or intent and then we try to accommodate them
> > as best as possible.
> 
> Agree that it should be done "in background" and that a size threshold would be useful.  But who evaluates that threshold?  The bluez kernel components, which essentially implement a transport driver, should not be examining objects (files, phonebooks, etc) size to see if this threshold is met.  Therefore, it would seem Tim's suggestion of having the profile send a 'prefer_amp' bit would be useful, right?

I would do something like "prefer_amp when over 100kb" or something. And
then the kernel needs to count. Meaning the L2CAP layer could easily
count this by itself.

Also just starting with setsockopt(bredr_only) and then later on just
doing setsockopt(prefer_amp) the userspace application would have
control over switching manually.

Since the polices are on a per socket basis, I don't see a big problem
with doing it like this.

The only thing that I don't want is a ioctl(switch_now_to_amp) since
that looks very wrong to me.

> > The other problem here is also that besides whatever the profiles
> > wants,
> > it might happen that the WiFi policy is stronger and only allows using
> > the WiFi device as WiFi or as AMP. And if WiFi wins, then we have to
> > rip
> > the AMP out of the system. At that point whatever the Bluetooth
> > profiles
> > wanted is pointless since the AMP controller is gone anyway.
> 
> Well, I think this is best managed by having the PAL announce its availability (and unavailability) to A2MP, using the spec's HCI events for this purpose.  A2MP can then be the agent to move the channel to AMP or not, accordingly.  For example, it might be that the 802.11 device is being used for an infrastructure link, and then that link goes away.  The PAL would then announce its availability to the BT stack (A2MP), and A2MP would then move the channel to AMP.

Agreed. My point was just that application can only set a policy. They
can't switch manually. If application would switch manually then they
need to check PAL availability etc. I don't want that complexity inside
the applications.

> > That said, nothing stops us from allowing to make our AMP polices
> > dynamic and allow the application to change it threshold during
> > lifetime. For example it starts out as BR/EDR only and then during the
> > usage of the link it decides that now AMP preferred would make sense.
> > In
> > that sense you would have manual switching to some level.
> 
> The only use case I see for manual switching is debugging.

That is fine. We can do that via debugfs.

Regards

Marcel

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Kevin Hayes]

SGkgTWFyY2VsLA0KDQo+ID4NCj4gPiBBZ3JlZSB0aGF0IGl0IHNob3VsZCBiZSBkb25lICJpbiBi
YWNrZ3JvdW5kIiBhbmQgdGhhdCBhIHNpemUNCj4gdGhyZXNob2xkIHdvdWxkIGJlIHVzZWZ1bC4g
IEJ1dCB3aG8gZXZhbHVhdGVzIHRoYXQgdGhyZXNob2xkPyAgVGhlDQo+IGJsdWV6IGtlcm5lbCBj
b21wb25lbnRzLCB3aGljaCBlc3NlbnRpYWxseSBpbXBsZW1lbnQgYSB0cmFuc3BvcnQNCj4gZHJp
dmVyLCBzaG91bGQgbm90IGJlIGV4YW1pbmluZyBvYmplY3RzIChmaWxlcywgcGhvbmVib29rcywg
ZXRjKSBzaXplDQo+IHRvIHNlZSBpZiB0aGlzIHRocmVzaG9sZCBpcyBtZXQuICBUaGVyZWZvcmUs
IGl0IHdvdWxkIHNlZW0gVGltJ3MNCj4gc3VnZ2VzdGlvbiBvZiBoYXZpbmcgdGhlIHByb2ZpbGUg
c2VuZCBhICdwcmVmZXJfYW1wJyBiaXQgd291bGQgYmUNCj4gdXNlZnVsLCByaWdodD8NCj4gDQo+
IEkgd291bGQgZG8gc29tZXRoaW5nIGxpa2UgInByZWZlcl9hbXAgd2hlbiBvdmVyIDEwMGtiIiBv
ciBzb21ldGhpbmcuDQo+IEFuZA0KPiB0aGVuIHRoZSBrZXJuZWwgbmVlZHMgdG8gY291bnQuIE1l
YW5pbmcgdGhlIEwyQ0FQIGxheWVyIGNvdWxkIGVhc2lseQ0KPiBjb3VudCB0aGlzIGJ5IGl0c2Vs
Zi4NCg0KV2hhdD8gIExldCdzIHNheSB0aGUgZWZmZWN0IHdlIHdhbnQgaXMgdGhhdCBpZiB0aGUg
b2JqZWN0IGlzIGdyZWF0ZXIgdGhhbiwgc2F5LCAxMCBtZWdhYnl0ZXMsIHRoZW4gd2Ugd2FudCB0
byB1c2UgQU1QIGZvciB0aGUgdHJhbnNmZXIuICBXaXRoIHlvdXIgc2NoZW1lLCB5b3Ugd2FudCB0
aGUga2VybmVsIHRvIGNvdW50IHVwIHRvIDEwIG1lZ2FieXRlcywgVEhFTiBzd2l0Y2ggb3ZlciB0
byBBTVA/DQpObywgeW91IGRvbid0LCBoZSBzYXlzIHJoZXRvcmljYWxseS4gIDopICANCg0KPiAN
Cj4gQWxzbyBqdXN0IHN0YXJ0aW5nIHdpdGggc2V0c29ja29wdChicmVkcl9vbmx5KSBhbmQgdGhl
biBsYXRlciBvbiBqdXN0DQo+IGRvaW5nIHNldHNvY2tvcHQocHJlZmVyX2FtcCkgdGhlIHVzZXJz
cGFjZSBhcHBsaWNhdGlvbiB3b3VsZCBoYXZlDQo+IGNvbnRyb2wgb3ZlciBzd2l0Y2hpbmcgbWFu
dWFsbHkuDQoNCkhvdyBpcyB0aGlzIHJlYWxseSBkaWZmZXJlbnQgZnJvbSB5b3VyIGlvY3RsKHN3
aXRjaF9ub3dfdG9fYW1wKSBiZWxvdywgd2hpY2ggbG9va3MgdmVyeSB3cm9uZz8NCg0KPiANCj4g
U2luY2UgdGhlIHBvbGljZXMgYXJlIG9uIGEgcGVyIHNvY2tldCBiYXNpcywgSSBkb24ndCBzZWUg
YSBiaWcgcHJvYmxlbQ0KPiB3aXRoIGRvaW5nIGl0IGxpa2UgdGhpcy4NCj4gDQo+IFRoZSBvbmx5
IHRoaW5nIHRoYXQgSSBkb24ndCB3YW50IGlzIGEgaW9jdGwoc3dpdGNoX25vd190b19hbXApIHNp
bmNlDQo+IHRoYXQgbG9va3MgdmVyeSB3cm9uZyB0byBtZS4NCkFncmVlZC4NCg0KPiANCj4gPiA+
IFRoZSBvdGhlciBwcm9ibGVtIGhlcmUgaXMgYWxzbyB0aGF0IGJlc2lkZXMgd2hhdGV2ZXIgdGhl
IHByb2ZpbGVzDQo+ID4gPiB3YW50cywNCj4gPiA+IGl0IG1pZ2h0IGhhcHBlbiB0aGF0IHRoZSBX
aUZpIHBvbGljeSBpcyBzdHJvbmdlciBhbmQgb25seSBhbGxvd3MNCj4gdXNpbmcNCj4gPiA+IHRo
ZSBXaUZpIGRldmljZSBhcyBXaUZpIG9yIGFzIEFNUC4gQW5kIGlmIFdpRmkgd2lucywgdGhlbiB3
ZSBoYXZlDQo+IHRvDQo+ID4gPiByaXANCj4gPiA+IHRoZSBBTVAgb3V0IG9mIHRoZSBzeXN0ZW0u
IEF0IHRoYXQgcG9pbnQgd2hhdGV2ZXIgdGhlIEJsdWV0b290aA0KPiA+ID4gcHJvZmlsZXMNCj4g
PiA+IHdhbnRlZCBpcyBwb2ludGxlc3Mgc2luY2UgdGhlIEFNUCBjb250cm9sbGVyIGlzIGdvbmUg
YW55d2F5Lg0KPiA+DQo+ID4gV2VsbCwgSSB0aGluayB0aGlzIGlzIGJlc3QgbWFuYWdlZCBieSBo
YXZpbmcgdGhlIFBBTCBhbm5vdW5jZSBpdHMNCj4gYXZhaWxhYmlsaXR5IChhbmQgdW5hdmFpbGFi
aWxpdHkpIHRvIEEyTVAsIHVzaW5nIHRoZSBzcGVjJ3MgSENJIGV2ZW50cw0KPiBmb3IgdGhpcyBw
dXJwb3NlLiAgQTJNUCBjYW4gdGhlbiBiZSB0aGUgYWdlbnQgdG8gbW92ZSB0aGUgY2hhbm5lbCB0
bw0KPiBBTVAgb3Igbm90LCBhY2NvcmRpbmdseS4gIEZvciBleGFtcGxlLCBpdCBtaWdodCBiZSB0
aGF0IHRoZSA4MDIuMTENCj4gZGV2aWNlIGlzIGJlaW5nIHVzZWQgZm9yIGFuIGluZnJhc3RydWN0
dXJlIGxpbmssIGFuZCB0aGVuIHRoYXQgbGluaw0KPiBnb2VzIGF3YXkuICBUaGUgUEFMIHdvdWxk
IHRoZW4gYW5ub3VuY2UgaXRzIGF2YWlsYWJpbGl0eSB0byB0aGUgQlQNCj4gc3RhY2sgKEEyTVAp
LCBhbmQgQTJNUCB3b3VsZCB0aGVuIG1vdmUgdGhlIGNoYW5uZWwgdG8gQU1QLg0KPiANCj4gQWdy
ZWVkLiBNeSBwb2ludCB3YXMganVzdCB0aGF0IGFwcGxpY2F0aW9uIGNhbiBvbmx5IHNldCBhIHBv
bGljeS4gVGhleQ0KPiBjYW4ndCBzd2l0Y2ggbWFudWFsbHkuIElmIGFwcGxpY2F0aW9uIHdvdWxk
IHN3aXRjaCBtYW51YWxseSB0aGVuIHRoZXkNCj4gbmVlZCB0byBjaGVjayBQQUwgYXZhaWxhYmls
aXR5IGV0Yy4gSSBkb24ndCB3YW50IHRoYXQgY29tcGxleGl0eSBpbnNpZGUNCj4gdGhlIGFwcGxp
Y2F0aW9ucy4NCj4gDQo+ID4gPiBUaGF0IHNhaWQsIG5vdGhpbmcgc3RvcHMgdXMgZnJvbSBhbGxv
d2luZyB0byBtYWtlIG91ciBBTVAgcG9saWNlcw0KPiA+ID4gZHluYW1pYyBhbmQgYWxsb3cgdGhl
IGFwcGxpY2F0aW9uIHRvIGNoYW5nZSBpdCB0aHJlc2hvbGQgZHVyaW5nDQo+ID4gPiBsaWZldGlt
ZS4gRm9yIGV4YW1wbGUgaXQgc3RhcnRzIG91dCBhcyBCUi9FRFIgb25seSBhbmQgdGhlbiBkdXJp
bmcNCj4gdGhlDQo+ID4gPiB1c2FnZSBvZiB0aGUgbGluayBpdCBkZWNpZGVzIHRoYXQgbm93IEFN
UCBwcmVmZXJyZWQgd291bGQgbWFrZQ0KPiBzZW5zZS4NCj4gPiA+IEluDQo+ID4gPiB0aGF0IHNl
bnNlIHlvdSB3b3VsZCBoYXZlIG1hbnVhbCBzd2l0Y2hpbmcgdG8gc29tZSBsZXZlbC4NCj4gPg0K
PiA+IFRoZSBvbmx5IHVzZSBjYXNlIEkgc2VlIGZvciBtYW51YWwgc3dpdGNoaW5nIGlzIGRlYnVn
Z2luZy4NCj4gDQo+IFRoYXQgaXMgZmluZS4gV2UgY2FuIGRvIHRoYXQgdmlhIGRlYnVnZnMuDQo+
IA0KPiBSZWdhcmRzDQo+IA0KPiBNYXJjZWwNCj4gDQoNCg==

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Peter Krystad]

Hi Marcel and Kevin,

>> >
>> > Agree that it should be done "in background" and that a size
>> threshold would be useful.  But who evaluates that threshold?  The
>> bluez kernel components, which essentially implement a transport
>> driver, should not be examining objects (files, phonebooks, etc) size
>> to see if this threshold is met.  Therefore, it would seem Tim's
>> suggestion of having the profile send a 'prefer_amp' bit would be
>> useful, right?
>>
>> I would do something like "prefer_amp when over 100kb" or something.
>> And
>> then the kernel needs to count. Meaning the L2CAP layer could easily
>> count this by itself.
>
> What?  Let's say the effect we want is that if the object is greater than,
> say, 10 megabytes, then we want to use AMP for the transfer.  With your
> scheme, you want the kernel to count up to 10 megabytes, THEN switch over
> to AMP?
> No, you don't, he says rhetorically.  :)

If the policy was defined as "prefer_amp after n seconds" we would get the
desired effect without having to do any counting in the kernel.

>>
>> Also just starting with setsockopt(bredr_only) and then later on just
>> doing setsockopt(prefer_amp) the userspace application would have
>> control over switching manually.
>
> How is this really different from your ioctl(switch_now_to_amp) below,
> which looks very wrong?
>
>>
>> Since the polices are on a per socket basis, I don't see a big problem
>> with doing it like this.
>>
>> The only thing that I don't want is a ioctl(switch_now_to_amp) since
>> that looks very wrong to me.
> Agreed.
>
>>
>> > > The other problem here is also that besides whatever the profiles
>> > > wants,
>> > > it might happen that the WiFi policy is stronger and only allows
>> using
>> > > the WiFi device as WiFi or as AMP. And if WiFi wins, then we have
>> to
>> > > rip
>> > > the AMP out of the system. At that point whatever the Bluetooth
>> > > profiles
>> > > wanted is pointless since the AMP controller is gone anyway.
>> >
>> > Well, I think this is best managed by having the PAL announce its
>> availability (and unavailability) to A2MP, using the spec's HCI events
>> for this purpose.  A2MP can then be the agent to move the channel to
>> AMP or not, accordingly.  For example, it might be that the 802.11
>> device is being used for an infrastructure link, and then that link
>> goes away.  The PAL would then announce its availability to the BT
>> stack (A2MP), and A2MP would then move the channel to AMP.
>>
>> Agreed. My point was just that application can only set a policy. They
>> can't switch manually. If application would switch manually then they
>> need to check PAL availability etc. I don't want that complexity inside
>> the applications.
>>
>> > > That said, nothing stops us from allowing to make our AMP polices
>> > > dynamic and allow the application to change it threshold during
>> > > lifetime. For example it starts out as BR/EDR only and then during
>> the
>> > > usage of the link it decides that now AMP preferred would make
>> sense.
>> > > In
>> > > that sense you would have manual switching to some level.
>> >
>> > The only use case I see for manual switching is debugging.
>>
>> That is fine. We can do that via debugfs.
>>
>> Regards
>>
>> Marcel
>>
>
> \x04èº{.nÇ+‰·Ÿ®‰­†+%ŠËlzwm…ébë§²æìr¸›zX§»\x16å¹ëh¢ØbžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&¢ø\x1e®G«éh®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš

Regards,

Peter.

-- 

Peter Krystad

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Marcel Holtmann]

Hi Peter,

> >> > Agree that it should be done "in background" and that a size
> >> threshold would be useful.  But who evaluates that threshold?  The
> >> bluez kernel components, which essentially implement a transport
> >> driver, should not be examining objects (files, phonebooks, etc) size
> >> to see if this threshold is met.  Therefore, it would seem Tim's
> >> suggestion of having the profile send a 'prefer_amp' bit would be
> >> useful, right?
> >>
> >> I would do something like "prefer_amp when over 100kb" or something.
> >> And
> >> then the kernel needs to count. Meaning the L2CAP layer could easily
> >> count this by itself.
> >
> > What?  Let's say the effect we want is that if the object is greater than,
> > say, 10 megabytes, then we want to use AMP for the transfer.  With your
> > scheme, you want the kernel to count up to 10 megabytes, THEN switch over
> > to AMP?
> > No, you don't, he says rhetorically.  :)
> 
> If the policy was defined as "prefer_amp after n seconds" we would get the
> desired effect without having to do any counting in the kernel.

that would work as well. We will see what works out best by giving
application the least amount of hassle :)

Regards

Marcel

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Gustavo F. Padovan]

Hi Peter,

* Peter Krystad <pkrystad@codeaurora.org> [2010-08-02 18:30:34 -0700]:

> 
> Hi Marcel and Kevin,
> 
> >> >
> >> > Agree that it should be done "in background" and that a size
> >> threshold would be useful.  But who evaluates that threshold?  The
> >> bluez kernel components, which essentially implement a transport
> >> driver, should not be examining objects (files, phonebooks, etc) size
> >> to see if this threshold is met.  Therefore, it would seem Tim's
> >> suggestion of having the profile send a 'prefer_amp' bit would be
> >> useful, right?
> >>
> >> I would do something like "prefer_amp when over 100kb" or something.
> >> And
> >> then the kernel needs to count. Meaning the L2CAP layer could easily
> >> count this by itself.
> >
> > What?  Let's say the effect we want is that if the object is greater than,
> > say, 10 megabytes, then we want to use AMP for the transfer.  With your
> > scheme, you want the kernel to count up to 10 megabytes, THEN switch over
> > to AMP?
> > No, you don't, he says rhetorically.  :)
> 
> If the policy was defined as "prefer_amp after n seconds" we would get the
> desired effect without having to do any counting in the kernel.

In both cases we have to take in account the total size of the file, or
the estimated time of transfer, so we can avoid to move to AMP when the
transfer is about to end.

-- 
Gustavo F. Padovan
http://padovan.org

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Tim Monahan-Mitchell]

Hi, Gustavo and Marcel,

> Hi Peter,
>
> * Peter Krystad <pkrystad@codeaurora.org> [2010-08-02 18:30:34 -0700]:
>
>>
>> Hi Marcel and Kevin,
>>
>> >> >
>> >> > Agree that it should be done "in background" and that a size
>> >> threshold would be useful.  But who evaluates that threshold?  The
>> >> bluez kernel components, which essentially implement a transport
>> >> driver, should not be examining objects (files, phonebooks, etc) size
>> >> to see if this threshold is met.  Therefore, it would seem Tim's
>> >> suggestion of having the profile send a 'prefer_amp' bit would be
>> >> useful, right?
>> >>
>> >> I would do something like "prefer_amp when over 100kb" or something.
>> >> And
>> >> then the kernel needs to count. Meaning the L2CAP layer could easily
>> >> count this by itself.
>> >
>> > What?  Let's say the effect we want is that if the object is greater
>> > than, say, 10 megabytes, then we want to use AMP for the transfer.
>> > With your scheme, you want the kernel to count up to 10 megabytes,
>> > THEN switch over to AMP?
>> > No, you don't, he says rhetorically.  :)
>>
>> If the policy was defined as "prefer_amp after n seconds" we would get
>> the desired effect without having to do any counting in the kernel.
>
> In both cases we have to take in account the total size of the file, or
> the estimated time of transfer, so we can avoid to move to AMP when the
> transfer is about to end.

Right! Don't want to switch to AMP just to push those last 100 bytes :)

Since the kernel does not know the total object size to be transferred,
(right?), I've yet to come up with any 'threshold' ideas the kernel can
make. Note that the transfer could be one huge file or many small ones.

--
Tim Monahan-Mitchell
Employee of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Marcel Holtmann]

Hi Kevin,

> > > Agree that it should be done "in background" and that a size
> > threshold would be useful.  But who evaluates that threshold?  The
> > bluez kernel components, which essentially implement a transport
> > driver, should not be examining objects (files, phonebooks, etc) size
> > to see if this threshold is met.  Therefore, it would seem Tim's
> > suggestion of having the profile send a 'prefer_amp' bit would be
> > useful, right?
> > 
> > I would do something like "prefer_amp when over 100kb" or something.
> > And
> > then the kernel needs to count. Meaning the L2CAP layer could easily
> > count this by itself.
> 
> What?  Let's say the effect we want is that if the object is greater than, say, 10 megabytes, then we want to use AMP for the transfer.  With your scheme, you want the kernel to count up to 10 megabytes, THEN switch over to AMP?
> No, you don't, he says rhetorically.  :)  

we will see what works out best. I am open for ideas. As I said before,
I know what I don't want for sure. The rest is open for testing and
figuring out if it works or not.

> > Also just starting with setsockopt(bredr_only) and then later on just
> > doing setsockopt(prefer_amp) the userspace application would have
> > control over switching manually.
> 
> How is this really different from your ioctl(switch_now_to_amp) below, which looks very wrong?

The difference is that you change a policy. setsockopt(prefer_amp)
doesn't mean you get switched. It just says that you prefer using an AMP
at this point.

Most application that expect a lot of data would always set the policy
to prefer AMP and if we have the PAL availability then it will switch
right away to AMP.

However with OBEX it might be that you wanna read the first package
first with BR/EDR only and only after knowing the file size make a
decision to prefer AMP or not.

We will see what works out best.

Regards

Marcel

RE: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Kevin Hayes]

SGkgYWdhaW4gTWFyY2VsLA0KDQo+IEhvd2V2ZXIgd2l0aCBPQkVYIGl0IG1pZ2h0IGJlIHRoYXQg
eW91IHdhbm5hIHJlYWQgdGhlIGZpcnN0IHBhY2thZ2UNCj4gZmlyc3Qgd2l0aCBCUi9FRFIgb25s
eSBhbmQgb25seSBhZnRlciBrbm93aW5nIHRoZSBmaWxlIHNpemUgbWFrZSBhDQo+IGRlY2lzaW9u
IHRvIHByZWZlciBBTVAgb3Igbm90Lg0KDQpFeGFjdGx5LiAgRm9yIE9QUCwgUEJBUCwgQklQLCBG
VFAsIHlvdSBrbm93IHRoZSBmaWxlIHNpemUgcHJldHR5IHF1aWNrbHksIG5vIGNvdW50aW5nIHJl
cXVpcmVkLg0KQW5kIGlmIHlvdSBoYXZlIGEgcG9saWN5IG9mICJ1c2UgQU1QIGlmIG9iamVjdCBi
aWdnZXIgdGhhbiBYIiwgdGhlbiB5b3UgZG9uJ3Qgd2FudCB0byBzcGVuZCBjeWNsZXMgdXNpbmcg
QlIvRURSIGlmIHlvdSBuZWVkIHRvIHhmZXIgYW4gb2JqZWN0IGV2ZW4gb25lIHNpbmdsZSBvY3Rl
dCBiaWdnZXIgdGhhbiBYLiAgQU1QIGVhcmx5LCBBTVAgb2Z0ZW4uICA6KQ0KDQo+IA0KPiBXZSB3
aWxsIHNlZSB3aGF0IHdvcmtzIG91dCBiZXN0Lg0KUG9saWN5IGlzIGEgd29uZGVyZnVsIHRoYW5n
LiAgOikNCg0KCUsrKw0KDQoNCg0K

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[David Vrabel]

Marcel Holtmann wrote:
> 
> That said, nothing stops us from allowing to make our AMP polices
> dynamic and allow the application to change it threshold during
> lifetime. For example it starts out as BR/EDR only and then during the
> usage of the link it decides that now AMP preferred would make sense. In
> that sense you would have manual switching to some level.

If the policy is dynamic throughout the lifetime of the connection then
that's okay for best effort links.

I think applications (especially those that stream real-time data at
high rates) will need to know the currently available bandwidth.  This
will be useful for even simple file transfer profiles -- if that file
transfer is going to take 100x as long the user probably want to know
about this so they can (for example) turn HS mode on the other device.

This information could be conveyed in some sort of "channel move
complete" event or a more generic "available bandwidth changed" event.

Applications requiring guaranteed links will need some way of supplying
extended flow specifications.

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR

[Marcel Holtmann]

Hi David,

> > That said, nothing stops us from allowing to make our AMP polices
> > dynamic and allow the application to change it threshold during
> > lifetime. For example it starts out as BR/EDR only and then during the
> > usage of the link it decides that now AMP preferred would make sense. In
> > that sense you would have manual switching to some level.
> 
> If the policy is dynamic throughout the lifetime of the connection then
> that's okay for best effort links.
> 
> I think applications (especially those that stream real-time data at
> high rates) will need to know the currently available bandwidth.  This
> will be useful for even simple file transfer profiles -- if that file
> transfer is going to take 100x as long the user probably want to know
> about this so they can (for example) turn HS mode on the other device.
> 
> This information could be conveyed in some sort of "channel move
> complete" event or a more generic "available bandwidth changed" event.

so here you have the following problem, the only interface you get from
an application point of view is a L2CAP socket. So you have to work with
these constraints. Potentially we can provide something additional via
the OOB msg structs (like we do for timestamps), but I am really careful
in adding to much into these ones.

Regards

Marcel