NG Ethernet Forum

The evolution of Ethernet has a major break between the 100 Mbps Ethernet with CSMA/CD and the Gigabit network, which is not a real "Ether" net anymore.
Since only point-to-point links interconnect the neighboring switches with one another, there is no longer a limitation in segment length and line speed.
The "original" Ethernet needed to detect signal collisions for all stations on the Ether. Hence the slot time (twice the propagation time) and minimum frame size. A constant minimum frame size and an increased line speed must lead to a shrinking segment size. In order to end up with sensible segment sizes, the line speed can not be increased indefinitely for traditional CSMA/CD networks.

The "Gigabit network" however does no longer care about CSMA/CD and can not run into signal collisions due to the exclusively available p2p links.

This, however, raises another issue. CSMA/CD collisions yielded an automatic slow down of data senders in the case of over utillisation.
Exclusively available p2p links, however, are always free to be used by the sending device, which may easily lead to overloaded nodes in the network. Just imagine a 8-port switch with 7 in-ports, which all need to transfer frames to the same out-port.

There ought to be a sort of brake system to be implemented, which slows down the senders in such congestion situations.
This flow control mechanism has been implemented by means of the PAUSE frames. MAC controllers of neighboring nodes can exchange those control frames in order to actively prevent congestion in the network.
Theses control frames are (as far as I know) currently only defined for this "PAUSE" frame and will certainly be available in 100G Ethernet systems as well.

However, this flow control only affects the actual point-to-point link and indirectly affects the other links and hierarchy layers. This "flow control brake" needs quite some time until the actual data source (presumably the sending end system) gets slowed down as well.
It is hard to judge, when the brake should be activated in order to start the slow down in time.

I therefor suggest another control frame to be introduced, which pro-actively starts a sort of "mild" flow control action far sooner than the actual sending PAUSE should be initiated.
This "PRIORITY_PAUSE" control frame should indicate the usual PAUSE count together with a priority value for priority tagged frames.

What does this mean? Well, this "PAUSE" is only valid for untagged frames and tagged frames with a priority value lower or equal the signaled priority value. All 'high priority' frames can still be send out as usual.

With the "PRIORITY_PAUSE" control frame in place, an Ethernet switch could far sooner slow down unimportant traffic (or less time critical traffic) from its sending neighbor before it actually requests a complete sending PAUSE.

Standardizing a new Opcode for the "PRIORITY_PAUSE" control frame should not be difficult and the extended MAC control functionality would greatly improve the Ethernet transmission for high priority frames.
100g Ethernet VoIP traffic carrying Ethernets would certainly benefit from this small improvement in MAC control functionality.