3

I have recently seen a Debian forum that mentioned pause frames should be discarded by the MAC layer and if not the driver should discard them. Is this true? How does a host actually throttle back traffic if it received a pause frame from a switch?

I am trying to get a better understanding of Ethernet flow control. If the above statement is true, what does passed to the host really mean?

Improve this question

2 Answers 2

Reset to default
3

There are three ways you can handle flow control:

  1. If you're overloaded, you drop data on the floor.
  2. If you can't provide service for a request from a higher layer, typically because your local queue is full, you return an error to that higher layer.
  3. You proactively notify higher layers that they need to slow down.

At the Ethernet layer, method 3 is supported through pause frames. Often higher layers don't support method 3, but instead support method 2. When a layer has a layer below it that supports method 3 but the layer above it only supports method 2, it can stop passing data to lower layers temporarily, causing method 2 to apply to higher layers.

Or, to put it more concretely, when you receive a pause frame you stop your sending engine and set a timer to restart the sending engine in the appropriate time. While the sending engine is stopped, your local queues will fill up with data from higher layers. If they get full, you return "busy" errors to the higher layers and they handle that however is appropriate.

Improve this answer
5
  • So how does a pause frame get sent up the stack and in turn have the NIC slow down its sending traffic? The ethernet controllers I have support flow control, but I can't determine why traffic doesn't "pause".
    – user_ABCD
    Jan 26, 2016 at 23:21
  • 4
    The pause frame doesn't get sent up the stack. The low layer of the stack simply stops reading frames from the queue. When the queue gets full, higher layers detect this when their "add packet to queue" functions fail. (Read the last paragraph.)
    – David Schwartz
    Jan 26, 2016 at 23:22
  • I am quite new to all this, but if I understand you correctly, what causes me to stop reading frames from the queue? Using ethtool, I can see I am receiving pause frames from the switch. But my udp application never slows down in regards to a bps.
    – user_ABCD
    Jan 26, 2016 at 23:34
  • 1
    I don't know the specific of your UDP application (and platform), but typically it's whatever mechanism would handle the case where there were no pause frames. Since you can also overload non-local, non-Ethernet links, you can't rely on pause frames for UDP transmit pacing, and usually there's no point in making two mechanisms. If your platform does propagate the information up all the way to user space, you'd typically detect it because a sendto on a non-blocking UDP socket would return a "would block" indication.
    – David Schwartz
    Jan 26, 2016 at 23:38
  • Hmmm. I am pretty sure I understand you. Is there a good way to determine if I am even handling the pause frames? Two things I currently know are I am in fact receiving pause frames (ethtool) and throughput (wireshark) never seems to change. Almost like higher layers never do anything when I receive the pause frames.
    – user_ABCD
    Jan 27, 2016 at 21:17
3

Ethernet flow control, so far, has been a failed experiment, because it often causes head-of-line blocking problems. Switches should not send pause frames to hosts. I believe Cisco switches cannot be configured to send pause frames; enabling Ethernet flow control on a Cisco switch just causes it to honor pause frames it receives. Hosts are wise to ignore received pause frames.

If the switch can't handle the transmission, it should drop the frame. Higher layers, most notably TCP, use dropped frames to know when congestion has occurred and when to back off. Failing to drop frames causes TCP Congestion Control to fail, typically resulting in bufferbloat.

Improve this answer
6
  • Why should a switch not send pause frames? I have a netgear switch that does send them to hosts. How does one host tell another host to slow down?
    – user_ABCD
    Jan 26, 2016 at 23:18
  • @user_ABCD Read up on head-of-line blocking. Imagine a switch connected to a GigE server, a GigE client, and a 100Mbps client, and both clients are downloading from the server. The switch's input buffer from the server might fill up because the packets can't be sent to the 100Mbps client fast enough. Then the switch sends a pause frame to the server, hurting the GigE client. It turns out it's better to handle congestion by just dropping frames at the Ethernet layer, which allows the upper layers to figure out when to slow down.
    – Spiff
    Jan 27, 2016 at 0:55
  • This doesn't actually answer what happens when pause frames are used...
    – u1686_grawity
    Jan 27, 2016 at 5:42
  • @Spiff are you suggesting that once a switch's input buffer is full, it sends pause frames to all ports with flow control enabled? Essentially slowing down the entire network?
    – user_ABCD
    Jan 27, 2016 at 20:26
  • @user_ABCD No, just the server port in my example. If a switch has separate per-port input buffers on each port, and the input buffer on the server port is full because of the slow client, the switch might send a pause frame to just the server, which blocks the server from servicing other clients, such as the fast client.
    – Spiff
    Jan 27, 2016 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .