Loading ...
Sorry, an error occurred while loading the content.

ECN (RFC2481) question

Expand Messages
  • Florian-Daniel Otel
    Dear all, I have a question regarding the ECN as specified in RFC2481. In Section 5, page 4 it is stated that: [..] we do not recommend such behavior as the
    Message 1 of 1 , Sep 6, 2000
    • 0 Attachment
      Dear all,

      I have a question regarding the ECN as specified in RFC2481. In
      Section 5, page 4 it is stated that:

      [..]
      we do not recommend such behavior as the slow-start of
      Tahoe TCP in response to a packet drop, or Reno TCP's wait of roughly
      half a round-trip time during Fast Recovery
      [..]


      The problem I have w/ it is that, as stated in section 6.1.2, the
      sender will half its cwnd (and set ssthresh) upon the receipt of an
      ECN-Echo ACK. But assuming that ACK-clocking was running and we
      didn't have any losses in the last RTT we have a full cwnd of data
      outstanding at the time we receive this ECN-Echo ACK. By halving the cwnd
      we still have to wait half a RTT (alternatively: wait for enough ACKs
      accounting for half of cwnd of data to arrive to decrease the amount of
      outstanding data to cwnd/2) before the sender is allowed to transmit more
      data.

      With many thanks,

      Florian.


      P.S: Maybe that I am wrong, but my reasoning behind "Reno was to wait
      half a RTT before sending more" data was similar (though in a different
      situation): We had to inflate cwnd back to at least its original size
      (i.e. when loss was signaled e.g. by 3 dup ACKs) before transmitting
      anything new and that meant waiting cwnd/2 worth of dup ACKs <=> half
      a RTT.
    Your message has been successfully submitted and would be delivered to recipients shortly.