Add Ben's comments.

diff --git a/doc/txt/tep113.txt b/doc/txt/tep113.txt
index edaf9fd8ebb1bb8c99d2889baa8c0883958ab1de..a251db7dc5a3f241d8e62a4c1b0467a6352f1877 100644 (file)
--- a/doc/txt/tep113.txt
+++ b/doc/txt/tep113.txt
@@ -278,6 +278,25 @@ stored in a queue separate from the data buffer, so a data packet to
 be transmitted may begin spooling into SerialP while SerialP is
 actively sending an acknowledgement.
 
+Only the PC-to-mote communication path supports acknowledgements.
+SerialP does not request acknowledgements from the PC for two reasons.
+First, acks are not perfect reliability: they are used on the PC-to-mote
+path to raise reliability to a usable level. In the case of the PC-to-mote
+path, the UART receive buffer is typically a single byte, so a high interrupt
+load can easily lose (and sometimes does) a byte. This is in contrast
+to the PC receive buffer, which is much larger and does not have to
+deal with overflow. Second, adding support for acks would increase
+the code size and complexity of the serial stack. As code space is
+often at a premium, this would add little needed functionality at significant
+cost. Of course, any application that
+requires perfect reliability may layer its own scheme on top of the
+serial protocol.
+
+The acknowledgement protocol is stop-and-wait to minimize buffering on
+the mote side. This is considered more important on memory constrained
+devices than increased throughput in the PC-to-mote direction, which
+most applications only use for occasional contro transmissions.
+
 
 3.4 Dispatcher: SerialDispatcherC
 --------------------------------------------------------------------