diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml
index f789079..b75d098 100644
--- a/webapps/docs/cluster-howto.xml
+++ b/webapps/docs/cluster-howto.xml
@@ -210,6 +210,7 @@ should be completed:</p>
     Synchronous vs. asynchronous is configured using the <code>channelSendOptions</code>
     flag and is an integer value. The default value for the <code>SimpleTcpCluster/DeltaManager</code> combo is
     8, which is asynchronous.
+    See the <a href="config/cluster.html#SimpleTcpCluster_Attributes">configuration reference</a> for more discussion on the various <code>channelSendOptions</code> values. 
 </p>
 <p>
     For convenience, <code>channelSendOptions</code> can be set by name(s) rather than integer,
diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml
index 36bbf0d..6a47eb9 100644
--- a/webapps/docs/config/cluster.xml
+++ b/webapps/docs/config/cluster.xml
@@ -145,6 +145,33 @@ Tomcat cluster. These include:</p>
       to the order in which they were sent.
       </p>
       <p>
+      	The various <code>channelSendOptions</code> values offer a tradeoff between throughput on the sending
+      	node and the reliability of replication should the sending node fail. Here are some common options. In this discussion
+      	"message" could be any message sent between the nodes, but in the context of this dicussion it applies to session changes
+      	being replicated to other nodes.
+      	<br/> 
+      	<code>channelSendOptions="8"</code>
+      	As far as the sender is concerned, the message is sent
+				as soon as it has been placed in the queue on the sender for
+				transmission to the other nodes. The message may not reach all of the 
+				recipient nodes and may not be successfully processed on those nodes that it does reach. 
+				This option offers the most throughput on the sender but the least reliability, as the 
+				triggering request will complete without any knowledge of the success/failure of the session replication.
+      	<br/>
+      	<code>channelSendOptions="2"</code>
+      	The sender will block the completion of the current request until all of the receiving nodes 
+      	have acknowledged that they have received the message, but have not necessarily processed
+      	that message. 
+      	This option will result in less throughput on the sending node, because the message must be transmitted
+      	and the acknowledgement received, but the reliability is greater than the asynchronous model. 
+      	<br/>
+      	<code>channelSendOptions="6"</code>
+      	The sender will block the completion of the current request until
+				all of the receiving nodes have acknowledged that they have received <u>and</u>
+				processed the message.
+				This option will have the least throughput (of these three) but the greatest reliability.
+      </p>
+      <p>
       You may also set these options as a comma separated string, e.g. "async, multicast", which
       will be translated into <code>Channel.SEND_OPTIONS_ASYNCHRONOUS | Channel.SEND_OPTIONS_MULTICAST</code>
       <br/>