Hi,
The short question: Does the Linux TCP implementation support the ECN
timeout suggested in rfc2481?
Some longer:
While experimenting with an ECN-marking queue (BLUE) on Linux I found
packet marking probability to reach 1.0 very early, eg. with 100 TCP
connections on a 10 Mbit Ethernet with a 50 kB buffer.
This seems to me the kind of problem which is mentioned in the BLUE paper
(http://www.thefengs.com/wuchang/work/CSE-TR-387-99.pdf, Chapter 3.4, Page
11: "The effects of ECN timeouts").
The above paper states that FreeBSD 2.2.7 + ALTQ 1.1.2 does not implement
the timeout.
I have tried to seek in the Linux 2.4.3 source to see whether Linux
implements it, but have not find traces of that (but I can be wrong, of
course).
ftp://ftp.ee.lbl.gov/ECN/README.ECN doesn't declare nor supporting, nor
ignoring the subject, but anyway it is quite old (isn't it outdated?).
To see what timeout I am talking about:
rfc2481:
... However, the value of the congestion window is
bounded below by a value of one MSS. If the sending TCP were to
continue to send, using a congestion window of 1 MSS, this results in
the transmission of one packet per round-trip time. We believe it is
desirable to still reduce the sending rate of the TCP sender even
further, on receipt of an ECN-Echo packet when the congestion window
is one. We use the retransmit timer as a means to reduce the rate
further in this circumstance. Therefore, the sending TCP should also
reset the retransmit timer on receiving the ECN-Echo packet when the
congestion window is one. The sending TCP will then be able to send
a new packet when the retransmit timer expires. ...
Without this mechanism, one should need an (MSS * num_of_connections)
size txbuffer on a bottleneck link to totally avoid packet losses even
when marking every packet with ECN CE. :(
Regards,
--
Bartok Istvan
|