I have a doubt regarding the use of ECN with WRED.
R1 ----- R2
if we have 2 routers R1 & R2 connected on a FR-link.
we have confgured a policy-map on R1 with a class-map for FTP traffic. this class also configured with WRED(ECN enabled).
bandwidth percent 1
FTP server is placed behind R2 router. if there is congestion on the link and there is packet drop on class-map FTP, will R1 send the congestion notification to R2?
I mean to ask that ECN bit is used to convey the ocngestion notification to remote router?
Thanks for replying in advance
ECN's purpose isn't to notify routers of congestion, its purpose is to notify the transmission source there's congestion without dropping packets.
In concept, ECN is much like frame-relay's FECNs and BECNs.
A lot of host stack's don't process ECN, although I think Vista's NextGen stack does. Since support for ECN isn't common, I would suggest you don't use it.
Thanks for the reply.
But my question is if R1----R2 is connected through frame-relay link and traffic source is behind R2, will R1 set the ECN bit and packet will be recieved by source to slow down?
2.) ECN bit set packet can be sent on FR-link or it is only for point-to-point link
If the traffic source is behind R2, R1 wouldn't normally set ECN on inbound traffic, especially with WRED except perhaps for an internal facing interface, e.g. WAN faster than LAN - like OC3 to 100 Mbps Ethernet. A policer on either R1 or R2 could clock the high volume outbound from behind R2 and might also mark ECN for too fast traffic.
What would normally happen, I believe, is R2 using WRED could set ECN for the heavy flow outbound, such as on a congested WAN interface, the receiving host reflects the ECN, and the sending host slows down.
ECN is IP, link type shouldn't matter.
Thanks for the reply,
You mean to say that we need to configure WRED with ECN on the same router where the traffic source resides.
DO you mean if traffic source is behind R2, we need to configure WRED with ECN as a outbound policy on R2 and if the queue is full, R2 will send a message back in LAN segment to the source to slow down?
Thanks for replying in advance.
As I understand ECN, in principle it works much like frame-relays's FECN/BECN, but at the IP (or TCP) level, host-to-host.
If the source of traffic is behind R2, R2 would see the heavy traffic volume from the source outbound. It could see this as queue congestion. R2 would then tag outbound packets with ECN, which informs the receiver, not the sender, there's congestion (much like frame-relay's FECN). The receiver then sends ECN-echo back to the source that it has been notified of congestion (much like frame-relay's BECN). The source seeing this should slow its transmission rate.
As far as I know, R2 would not directly send ECN marked packets to the source.
The ECN bit would be set by a router with WRED being in the random drop range. It replaces the drop of a packet with an ECN bit marking, if the flow is ECN capable.
The packet with ECN bit set is received by the receiver, who would then adjust the receive window in a TCP session, just like it would have, if a dropped packet was detected.
The receive window in TCP translates to throughput with
TCP throughput = window size/round trip time
So the source would not know anything about the congestion, but rather follow the receivers window size adjustments thus adjusting the throughput of the flow.
The ECN idea has some challenges, imho. Any misbehaving host gets an advantage. Assume I modify my TCP stack so that I am ECN capable, but after receiving ECN bits set I will NOT lower the window size, hence not lowering my throughput. If all other systems throttle their sessions because of the congestion experienced, whereas I send at full throughput, misbehaving is encouraged.
With all the creative file sharers in the internet (providing f.e. clients capable of setting DSCP bits to get an advantage) I doubt that an ISP easily can rely on ECN bits instead of packet dropping with WRED.
In an Enterprise environment, where one can control all involved gear this might be a different situation.
"The ECN bit would be set by a router with WRED being in the random drop range. It replaces the drop of a packet with an ECN bit marking, if the flow is ECN capable."
"The packet with ECN bit set is received by the receiver, who would then adjust the receive window in a TCP session, just like it would have, if a dropped packet was detected.
So the source would not know anything about the congestion, but rather follow the receivers window size adjustments thus adjusting the throughput of the flow. "
That's not my understanding, although I could be mistaken.
I was just reviewing the RFCs, and my impression was the receiver echos the ECN notification to the sending source which is supposed to repond as if the packet was dropped. I.e., receiver doesn't adjust its receive window, but sender should adjust its congestion window.
Just now I'm re-reading RFC3168, sections 6.1.2, The TCP Sender, and 6.1.3, The TCP Receiver. The prior RFC2481's same sections appear to be similar. I would appreciate reference to reduction of the receiver's receive window vs. reduction of the sender's congestion window.
Full ACK, Joseph, you are right.
P.S.: Considering the tricks my memory sometimes does on me, I never would like to be dependent on eye witnesses and a jury ...