diff --git a/doc/manual/docs/profiles.md b/doc/manual/docs/profiles.md
index eb19f5f9f..65881b093 100644
--- a/doc/manual/docs/profiles.md
+++ b/doc/manual/docs/profiles.md
@@ -172,7 +172,9 @@ bonding via the *gap_dedicated_bonding* function.
 ## SPP - Serial Port Profile
 
 The SPP profile defines how to set up virtual serial ports and connect
-two Bluetooth enabled devices.
+two Bluetooth enabled devices. Please keep in mind that a serial port does not 
+preserve packet boundaries if you try to send data as packets and read about
+[RFCOMM packet boundaries]({protocols/#sec:noRfcommPacketBoundaries}).
 
 ### Accessing an SPP Server on a remote device
 
diff --git a/doc/manual/docs/protocols.md b/doc/manual/docs/protocols.md
index ebeb1a7d3..03b0a2132 100644
--- a/doc/manual/docs/protocols.md
+++ b/doc/manual/docs/protocols.md
@@ -331,6 +331,26 @@ for the Serial Port Profile and other profiles used for
 telecommunication like Head-Set Profile, Hands-Free Profile, Object
 Exchange (OBEX) etc.
 
+### No RFCOMM packet boundaries {#sec:noRfcommPacketBoundaries}
+
+As RFCOMM emulates a serial port, it does not preserve packet boundaries. 
+
+On most operating systems, RFCOMM/SPP will be modeled as a pipe that allows
+to write a block of bytes. The OS and the Bluetooth Stack are free to buffer
+and chunk this data in any way it seems fit. In your BTstack application, you will
+therefore receive this data in the same order, but there are no guarantees as
+how it might be fragmented into multiple chunks.
+
+If you need to preserve the concept of sending a packet with a specific size
+over RFCOMM, the simplest way is to prefix the data with a 2 or 4 byte length field
+and then reconstruct the packet on the receiving side.
+
+Please note, that due to BTstack's 'no buffers' policy, BTstack will send outgoing RFCOMM data immediately 
+and implicitly preserve the packet boundaries, i.e., it will send the data as a single
+RFCOMM packet in a single L2CAP packet, which will arrive in one piece. 
+While this will hold between two BTstack instances, it's not a good idea to rely on implementation details
+and rather prefix the data as described.
+
 ### RFCOMM flow control {#sec:flowControlProtocols}
 
 RFCOMM has a mandatory credit-based flow-control. This means that two