UDP saturation, TCP effection question

[acole1]

If a router is sending UDP syslog packets over an MPLS WAN at such a rate that 100% of the bandwidth is being used, how much effect will this have on TCP traffic? I'm not sure to what extent backpressure, RED, or ECN are used.

 

[Railgun]

Need a lot more information than that. What router are you using? What, if any, QoS policies do you have enabled?

What is your BW?

The router will potentially drop something, regardless of UDP or TCP. If the TCP packet does get through, and the ack doesn't, or vice versa...well...I think you know how that will go.

Needless to say you're probably not receiving all syslog messages.

 

[SecurityTheatre]

If a router is sending UDP syslog packets over an MPLS WAN at such a rate that 100% of the bandwidth is being used, how much effect will this have on TCP traffic? I'm not sure to what extent backpressure, RED, or ECN are used.

UDP traffic does not perform any congestion avoidance and is, therefore, capable of saturating a connection in a non-recoverable way.

Backpressure routing is a theoretical concept not implemented on any production hardware that I'm aware of and requires coordination of multiple routers akin to a routing protocol.

RED (WRED, actually) is implemented in some gear, including Cisco, but all it does is start dropping packets in a "more fair" way to avoid problems with aggressive windowing. UDP does not respond to dropped packets and does not handle congestion avoidance, nor would it even be aware of congestion.

The same goes for ECN, which also just adds a flag at a point slightly below true saturation, which is supposed to make the session handler behave like it had just dropped a packet, and throttle back the transmission window. Again, UDP doesn't handle congestion avoidance, so it doesn't even make sense for UDP to be subject to ECN (as in, it isn't theoretically possible for UDP in Layer 4 to do this).

If you are transmitting traffic (like Syslog) via UDP that is not bandwidth aware, you will saturate your line with UDP traffic. TCP traffic will then fall back to extremely small TCP window sizes with a high retransmission rate and you will struggle to send much at all through the link.

The proper configuration is to use QoS to hard-limit UDP traffic on the router to some fraction of the available bandwidth, or dynamic QoS to do some more interesting endpoint-weight based QoS to be a bit more flexible.

 

[Emulex]

you can still change buffers and priority of packet size. this is common to let dns records go out faster, udp.

You always want your ACK/SACK/UDP small to make it otherwise you will congest further large packets.

ie if you get a request , send a response, but the ack for that response is dropped, all packets are worthless and will have to be resent.

Tune your network to have 10% free bandwidth too. don't run up to 100% ever. you can do this with simple traffic shaping

 

[SecurityTheatre]

you can still change buffers and priority of packet size. this is common to let dns records go out faster, udp.

What does DNS have to do with UDP and what do you mean "go out faster"? Do you mean that you prioritize UDP port 53 via QoS?

You always want your ACK/SACK/UDP small to make it otherwise you will congest further large packets.

small to make it? You are saying that you want UDP packets to be small? I think that's the question... The UDP traffic is already out there and you cannot change the nature of it, so how to deal with it?

ie if you get a request , send a response, but the ack for that response is dropped, all packets are worthless and will have to be resent.

I think you are trying to say that you really want your ACK to successfully reach the sender, to avoid retransmission issues. This is correct, but UDP doesn't have anything to do with this, especially since UDP is what would be causing the problems in this scenario.

Tune your network to have 10% free bandwidth too. don't run up to 100% ever. you can do this with simple traffic shaping

Agree.