Aggressive UDP flows

[GoncaloContente]

Hi,

I am reading about the DBL feature on the Cisco 4500E which protect the buffers from filling up with traffic that is identified as nonadaptive or belligerent flows such as aggressive UDP flows. Since my curiosity doesnt stop here, i am trying to understand how the supervisor engine identify this type of traffic, which characteristics has this traffic appart from being UDP.

Is this UDP traffic only?

Can someone provide me with examples of aggressive UDP flows or any other flows that are marked as belligerent flows?

Regards

Gonçalo Reis

[Peter Paluch · Accepted solution]

Hi Gonçalo,

DBL on Catalyst 4500 acts on flows. For DBL purposes, a flow is identified using the [SourceIP, DestinationIP, L4Proto, L4SrcPort, L4DstPort, VLAN] 6-tuple. It does not necessarily need to be UDP.

What DBL does is, on a per-egress-interface basis, keeping track of

• The number of flows currently handled
• The number of packets enqueued for each flow
• The total number of enqueued packets on the interface

When a packet is to be enqueued to an egress port, DBL computes the momentary dynamic limit for that port based on the current number of flows and the total number of currently enqueued packets on that port. For the packet, DBL identifies the flow, and checks how many packets of that flow are already enqueued. If their number is equal or higher to the momentary dynamic limit, the packet will be dropped, otherwise it will be accepted.

There might be internal tweaks to the details how DBL works, but the mechanism described above is the fundamental idea of DBL.

As for the examples of non-adaptive flows (NAFs), obviously, TCP flows are not typical representatives since TCP reacts to packet drops by backing off. Any kinds of UDP flows, whether they are unicast or multicast streams, would be the typical NAFs. However, if you - for example - get a switching loop with frames looping endlessly, and the frames would carry TCP segments of some TCP session, DBL would act quite effectively on these as well. Note that TCP segments looping as a result of a switching loop would also constitute a NAF.

Feel welcome to ask further!

Best regards,
Peter

[Joseph W. Doherty · Accepted solution]

"Any kinds of UDP flows, whether they are unicast or multicast streams, would be the typical NAFs."

I just wanted to add a note to Peter's statement. He's 100% correct, UDP itself is non-adaptive. However some applications using UDP will slow their rate if they detect packet loss. Often it's important to know how a particular UDP flow will behave because those that adapt their rate can benefit from drops, those that are non-adaptive either need to be not dropped (if possible) or often you might as well drop them all as many will be useless once you hit a certain drop percentage.

Also from the OP: ". . . protect the buffers from filling up with traffic that is identified as nonadaptive or belligerent flows such as aggressive UDP flows." As Peter also noted, DBL isn't limited to non-adaptive flows, UDP or belligerent/aggressive flows, it simply drops first from the flows consuming the most buffer space, since they are the flows proportionally filling more of the buffer. Also it's often not really that the flows are belligerent or aggressive, just all the combined flows, at that point in time, are exceeding the transmission rate that's available. DBL, with adaptive flows, tends to equalize the bandwidth provided to all the flows (subject to it).

Also BTW, DBL, I find a better/fairer way to drop packets then RED.

[GoncaloContente]

Hi Joseph
Thank you for re-enforcing and completing Peter's explanation.

[GoncaloContente]

Hi, Peter
Thank you for the reply, your explanation is quite clear and re-enforce what i suspected already. Most of the non adaptive flows are just UDP traffic from applications that are enabled by default on some Operating Systems and end up flooding the network with rubbish, like LLMNR, MDNS, SSDP, etc.

I am just wondering if there is any command to see which traffic is on the buffers or if its possible to see which traffic is dropped by protocol?

[Joseph W. Doherty]

"I am just wondering if there is any command to see which traffic is on the buffers or if its possible to see which traffic is dropped by protocol?"

Not that I'm aware of.

[Peter Paluch]

Hi Gonçalo, hi Joe,

Indeed, I am not aware of such a command, either. However, I think that we can at least say this: DBL works on egress queues, and you can display the statistics for those queues using show interface ... counter detail which will also show you the drops in the individual egress queues of the interface including DBL drops. By inspecting the mapping of DSCP/CoS classes to egress queues, you can at least partially guess which traffic class appears to contain aggressive flows, depending on which class exhibits increasing drops.

Best regards,
Peter

[Joseph W. Doherty]

Peter, yes I thought of that. The issue, though, it becomes more or less effective depending how you map traffic to a queue. Additionally, of course, different apps might be using the same tagging or conversely the same app traffic might have very different behavior based on particular flows. So, using this approach might be a bit misleading although, you're correct, it might answer Gonçalo's question. I.e. probably good you mentioned it.

[Peter Paluch]

Hi Joe,

Oh, yes, absolutely, no argument here :) It was just that if we're interested what traffic is being dropped by DBL, this is likely the closest we can get. The "closest" may still mean "impractically far", though :)

I am sincerely glad to have you around QoS-related topics here! You always bring a perspective to these topics, and I still keep learning myself. Thank you for that!

Best regards,
Peter

[GoncaloContente]

... and I am sincerely glad for your's and Joseph help.

I'll be asking more question soon. I  am sure :)

Goncalo Reis