home *** CD-ROM | disk | FTP | other *** search
/ ftp.ee.lbl.gov / 2014.05.ftp.ee.lbl.gov.tar / ftp.ee.lbl.gov / email / sf.97dec16.txt < prev    next >
Text File  |  1997-12-15  |  2KB  |  31 lines
  1. ECN, TCP, and congestion on the ACK-path:
  2. ----------------------------------------
  3.  
  4. >I have one general question, namely whether
  5. >pure acks have the ECN-aware bit set.  Becaue they're *not* actually
  6. >adaptive themselves.
  7.  
  8. For the initial TCP implementations with ECN, pure acks should not have
  9. the ECN-capable bit set.  This is because it is not completely obvious
  10. what the TCP sender should do in response to congestion on the
  11. ack-path.  Cut its window in half?  Or better, tell the receiver to
  12. send fewer acks, and to begin rate-pacing in compensation.
  13.  
  14. For current non-ECN-capable TCP implementations, the drop of a single
  15. pure ack packet does not generally result in a decrease in the
  16. subsequent arrival rate of ack packets.  For current TCP
  17. implementations, if a single ack packet is dropped, the TCP sender will
  18. refrain from whatever window increase it would have made if that ack
  19. packet had arrived, and when a subsequent ack arrives at the sender, the
  20. sender will send a burst of back-to-back packets.  Thus, for current
  21. TCP implementations, the main effect of a dropped ack packet is to
  22. prevent an increase in the TCP sender's congestion window, and to
  23. increase the burstiness of the sending process.
  24.  
  25. One benefit of ECN for TCP is that it opens the door for explicit
  26. congestion control on the ack path.  This is likely to be particularly
  27. useful for TCP connections over asymmetric paths, where the "return"
  28. path is relatively low-bandwidth.  But the ECN draft leaves the
  29. details for future research.
  30.  
  31.