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.
 
 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
 --------------------------------------------------------------------
 
 3.4 Dispatcher: SerialDispatcherC
 --------------------------------------------------------------------