cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
113
Views
5
Helpful
1
Replies
Difan_Zhao
Beginner

Does WRED consider for each flow?

I always have the question that whether the WRED cares about each traffic flow. Flow is defined by the 5-tuple attributes which are src/dst IP, src/dst port and protocol number. Or does it only care about the DSCP values? My platform is C9500-40X

 

For example, if I have two traffic flows, both with DSCP value of 0, going out of the same interface. One flow is significantly larger than the second. Would the switch calculate a higher drop probability on the packets with the larger flow? Would the end result be to throttle the larger flow more to give better chance for the small flow to go through? 

 

I understand that this would only affect TCP flows and the drop only happens when congestion is happening (when the queue is being filled up)

 

Thanks,

Difan

1 REPLY 1
Joseph W. Doherty
Hall of Fame Expert

"I always have the question that whether the WRED cares about each traffic flow."

WRED no (per flow - FRED, yes per flow - latter I suspect not supported on Cat 9Ks - I recall only some Cat 4K sups supported FRED [Flow based RED]).

"Or does it only care about the DSCP values?"

Only, no, but DSCP values could be (depends on WRED configuration i.e. can be very important).

"One flow is significantly larger than the second. Would the switch calculate a higher drop probability on the packets with the larger flow? Would the end result be to throttle the larger flow more to give better chance for the small flow to go through?"

That's an it depends answer.  I suspect how WRED works, or does what it does, is a bit unclear to you?

"I understand that this would only affect TCP flows and the drop only happens when congestion is happening (when the queue is being filled up)"

No (regarding TCP only) and no (only when being filled up).

I realize, at first glance, and with typical (W)RED documentation, it seems to be an outstanding congestion management solution (at least for TCP) and yet simple to use and configure.

(W)RED can be used for effective (TCP) congestion management, but getting it "right", within all its "quirks", is far, far from simple.  So much so, I recommend QoS non-experts, don't use it at all, except perhaps configured to implement tiered tail drop.

On the subject of (W)RED, I often suggest search the Internet on the subject and, for example, take note of all the variants of RED, trying to "improve" it and/or correct some of its "quirks".  Heck, even Dr. Floyd who first proposed RED, had an "improved" version not too long after.

One of REDs "quirks" is it might not drop any packets as a queue rapidly fills or it might drop packets, as they arrive, while the egress queue is empty.  (If you wonder how this might happen, it's because RED uses an "average" queue size, not current queue size.)

Also, the nature of traffic, today, is often very different from what existed when RED was first proposed.  Big difference managing FTP (then) using TCP, vs. HTTP/HTTPS (today) using TCP.

 

PS:

BTW, another difference between then and now, TCP depended on packets being dropped for flow rate management, but many modern TCP stacks also closely monitor RTT and slow their transmission rate if RTT suddenly increases.

Another then and now difference, that impacts RED, then hardware for "advanced decision" making was often rare, so a goal of RED was to be of light impact while routing packets (i.e. when T-1, 1.5Mbps, was "fast").  Today, hardware can do lots of "advanced decision" making, even when doing 100G, etc.