Updated EN_KCP Feature (markdown)

EN_KCP-Feature.md

@@ -22,6 +22,6 @@ TCP will try to reply ACK as late as possible(even TCP_NODELAY), which will caus
 
 There are two kinds of ARQ(Automatic Repeat reQuest) model responses: UNA (All segments before this number received, such as TCP) and ACK (The segment with this number received). For example, sender send 1,2,3,4,5 while receiver got 1,2,4,5. All segments will be retransmit for UNA, that is, receiver will reply UNA 3 two times when got 4,5, and sender will retransmit 3,4,5. It cost too much when only use ACK, receiver will reply ACK 1,2,4,5 for each received segment. KCP use better model of UNA and ACK, each packet use UNA but there is ACK packet when segment loss occurs.
 
-#### Flow Control
+#### Flow Control: Window backoff or Not
 
-   KCP use the same algorithm as TCP for congestion window, the send window size depends on: send buffer size, the receive peer buffer size, packets dropping rate and slow startup. User can config KCP to only use the send and receive buffer size, not use the last two factors, for fast transmission for very small packet but require realtime delivery. It's impressive to fast transmit in bad networking with packets dropped.
+In normal mode, KCP follows the congestion control algorithm as TCP, that is, the `cwnd` depends on: the size of send buffer, the size of peer receive buffer, congestion window backoff and slow startup. However, when transmitting small or realtime segments, KCP can ignore the last two factors, which means we won't use window backoff, but try to send more segments even though the network is heavy. It's impressive to fast transmit in heavy netowrk when segment loss occurs.