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)
"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.
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.
Listen: https://smarturl.it/CCRS9E25 Follow us: twitter.com/ciscochampions
With applications and users everywhere, the networks are now, more than ever, being tasked with delivering consistent protection while providing an exceptional user exper...
Listen: https://smarturl.it/CCRS9E24 Follow us: https://twitter.com/CiscoChampion
Cisco Radio Aware Routing addresses several of the challenges faced when merging IP routing and radio communications in mobile networks, especially those exhibiti...
Listen: https://smarturl.it/CCRS9E23 Follow us: https://twitter.com/CiscoChampion The Wi-Fi 6E Catalyst 9136 access point takes advantage of the 6-GHz band to produce a network that is more reliable and secure, with higher throughput, more ...
When moving from OSPFv2 to OSPFv3, there are many changes in the format of the LSAs Type, but the most known changes are: IP prefix informations are no longer carried in Type-1 LSA and Type-2 LSA, new LSAs Type 8 and 9 are added to carry these prefixes.