Random Early Detect and streaming video

Mon Nov 7 19:55:44 UTC 2022

I've been involved in service provider networks, small retail ISPs, for 20+
years now. Largely though, we've never needed complex QoS, as at
$OLD_DAY_JOB, we had been consistently positioned to avoid regular link
congestion by having sufficient capacity. In the few instances when we've
had link congestion, egress priority queuing met our needs. With a new
organization there is a set of circumstances that have resulted in a long
standing business decision to apply some rate-limiting/traffic management
during times of higher utilization to a subset of traffic. This traffic
happens to be ABR streaming video traffic. The thought was that a little
bit of packet loss that comes from RED or WRED could largely be absorbed in
the ABR playback client's innate behavior, and yes, possibly a drop in
video profile. These are acceptable business outcomes in this case. The
question I have for the smart people of this list is, given the specific
application that is receiving this treatment, is there any reason to apply
a RED behavior any appreciable amount before the bandwidth limit for this
application? It makes sense to me for interactive TCP traffic where you
want to apply some artificial control to the TCP window, but I *feel* like
ABR streaming video was designed to expect congestion, at least as the edge
of the customers home, and combine that with the buffering and we should
adjust the drop profile to kick in at a higher percentage. Today we use 70%
to start triggering the drop behavior, but my head tells me it should be
higher. The reason I am saying this is that we are dropping packets ahead
of full link congestion, yes that is what RED was designed to do, but I
surmise that we are making this application worse than is actually intended.

Hopefully my targeted vagurey has still left enough context intact to
receive some useful commentary back.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221107/57f84729/attachment.html>