diff --git a/showcases/tsn/trafficshaping/creditbasedshaper/CreditBasedShaperShowcase.anf b/showcases/tsn/trafficshaping/creditbasedshaper/CreditBasedShaperShowcase.anf index de249b09632..5e0451d5abe 100644 --- a/showcases/tsn/trafficshaping/creditbasedshaper/CreditBasedShaperShowcase.anf +++ b/showcases/tsn/trafficshaping/creditbasedshaper/CreditBasedShaperShowcase.anf @@ -5,9 +5,17 @@ - + @@ -424,17 +452,41 @@ utils.export_data_if_needed(df, props) - - + + - - - + + - - + - - - - - - - - - - - - - - - - - - @@ -515,6 +539,7 @@ utils.export_data_if_needed(df, props) + ]]> @@ -529,10 +554,10 @@ utils.export_data_if_needed(df, props) - @@ -594,53 +619,51 @@ utils.export_data_if_needed(df, props) ]]> + + + - - - - - + + + + + + + - - - - - + - - - - + + + + - - + + + + - - - + + - - - - - - + + - + @@ -1233,11 +1262,11 @@ utils.export_data_if_needed(df, props) - + - + - + @@ -1252,10 +1281,10 @@ utils.export_data_if_needed(df, props) - - + + - + @@ -1266,7 +1295,7 @@ utils.export_data_if_needed(df, props) - + @@ -1275,12 +1304,22 @@ utils.export_data_if_needed(df, props) - + +utils.export_data_if_needed(df, props)]]> @@ -1694,17 +1734,41 @@ utils.export_data_if_needed(df, props) - - + + - - - + + - - + - - - - - - - - - - - - - - - - - - @@ -1785,6 +1821,7 @@ utils.export_data_if_needed(df, props) + ]]> @@ -1799,10 +1836,10 @@ utils.export_data_if_needed(df, props) - @@ -1864,58 +1901,66 @@ utils.export_data_if_needed(df, props) ]]> + + + - - - - - + + + + + + + - - - - - + - - - - - - - + + + + + + + - + + + - - - + + - - - - - - + + - + +utils.export_data_if_needed(df, props)]]> @@ -2329,17 +2375,41 @@ utils.export_data_if_needed(df, props) - - + + - - - + + - - + - - - - - - - - - - - - - - - - - - @@ -2420,6 +2462,7 @@ utils.export_data_if_needed(df, props) + ]]> @@ -2434,10 +2477,10 @@ utils.export_data_if_needed(df, props) - @@ -2499,53 +2542,51 @@ utils.export_data_if_needed(df, props) ]]> + + + - - - - - + + + + + + + - - - - - + - - - + + + - - + + - + + + - - + - - - - - - + + - + - + - + - + @@ -4255,17 +4328,41 @@ utils.export_data_if_needed(df, props) - - + + - - - + + - - + - - - - - - - - - - - - - - - - - - @@ -4346,6 +4415,7 @@ utils.export_data_if_needed(df, props) + ]]> @@ -4360,10 +4430,10 @@ utils.export_data_if_needed(df, props) - @@ -4425,55 +4495,61 @@ utils.export_data_if_needed(df, props) ]]> + + + - - - - - + + + + + + + - - - - - + - - - - + + + + - - + + + + - - - + + - - - - - - + + - + @@ -4890,17 +4983,41 @@ utils.export_data_if_needed(df, props) - - + + - - - + + - - + - - - - - - - - - - - - - - - - - - @@ -4981,6 +5070,7 @@ utils.export_data_if_needed(df, props) + ]]> @@ -4995,10 +5085,10 @@ utils.export_data_if_needed(df, props) - @@ -5060,51 +5150,49 @@ utils.export_data_if_needed(df, props) ]]> + + + - - - - - + + + + + + + - - - - - + - - - - + + + + - - + + + + - - - + + - - - - - - + + diff --git a/showcases/tsn/trafficshaping/creditbasedshaper/doc/index.rst b/showcases/tsn/trafficshaping/creditbasedshaper/doc/index.rst index 758eeb3b537..8bdc935b0e8 100644 --- a/showcases/tsn/trafficshaping/creditbasedshaper/doc/index.rst +++ b/showcases/tsn/trafficshaping/creditbasedshaper/doc/index.rst @@ -4,45 +4,149 @@ Credit-Based Shaping Goals ----- -In this example we demonstrate how to use the credit-based traffic shaper. +Credit-based shaping (CBS), as defined in the IEEE 802.1Qav standard, is a +traffic shaping mechanism that regulates the transmission rate of Ethernet +frames to smooth out traffic and reduce bursts. + +In this showcase, we demonstrate the configuration and operation of credit-based shaping in INET +with an example simulation. + +.. **TODO** some interesting stuff to show? -> shaping in general increases delay even for high priority frames. but can overall decrease delay (as it decreases delay for lower priority frames) | INET version: ``4.4`` | Source files location: `inet/showcases/tsn/trafficshaping/creditbasedshaper `__ +Credit-Based Shaping Overview +----------------------------- + +The Credit Based Shaping (CBS) is an algorithm designed for +network traffic management. Its core function is to limit the bandwidth a +Traffic Class queue can transmit, ensuring optimal bandwidth distribution. +It helps smoothing out bursts by delaying the transmission of successive +frames. CBS helps in mitigating network +congestion in bridges and enhancing overall network performance. + +In CBS, each outgoing queue is associated with a credit counter. The credit +counter accumulates credits when the queue is idle, and consumes credits when +frames are transmitted. The rate at which credits are accumulated and consumed +is configured using parameters such as the `idle slope` and `send slope`. + +When the queue contains a packet to be transmitted, the credit counter is checked. If the +credit counter is non-negative, the frame is transmitted immediately. If the +credit counter is negative, the frame is held back until the credit counter +becomes non-negative. + +CBS Implementation in INET +-------------------------- + +In INET, the credit-based shaper is implemented by the +:ned:`Ieee8021qCreditBasedShaper` simple module. This module acts as a packet gate, +allowing packets to pass through only when it is open. It can be combined with a +packet queue to implement the credit-based shaper algorithm. + +The :ned:`Ieee8021qCreditBasedShaper` module has the following parameters: + +- :par:`idleSlope`: Determines the outgoing data rate of the shaper, measured in bits per second +- :par:`sendSlope`: The consumption rate of credits during transmission, measured in bits per second (default: idleSlope - channel bitrate) +- :par:`transmitCreditLimit`: credit limit above which the gate is open, measured in bits (default: 0) +- :par:`minCredit` and :par:`maxCredit`: a minimum and maximum limit for credits, measured in bits (default: no limit) + +The :par:`idleSlope` parameter determines the data rate at which the traffic will be limited, `as measured +in the Ethernet channel` (thus including protocol overhead). Typically, this is the only parameter that needs to be set, +as the others have reasonable defaults. + +The shaper allows packets to pass through when the number of credits is zero or +more. When the number of credits is positive, the shaper accumulates a burst +reserve. As defined in the standard, if there are no packets in the queue, the +credits are set to zero. + +To conveniently incorporate a credit-based shaper into a network interface, it +can be added as a submodule to an :ned:`Ieee8021qTimeAwareShaper`. The +:ned:`Ieee8021qTimeAwareShaper` module supports a configurable number of traffic +classes, pre-existing queues for each class, and can be enabled for Ethernet +interfaces by setting the :par:`enableEgressTrafficShaping` parameter in the +network node to ``true``. To utilize a credit-based shaper, the +``transmissionSelectionAlgorithm`` submodule of the time-aware shaper can be +overridden accordingly. As an example, here is a time-aware shaper module that +incorporates credit-based shaper submodules and supports two traffic classes: + +.. figure:: media/timeawareshaper_.png + :align: center + +Packets entering the time-aware shaper module are classified into different +traffic categories based on their PCP number using the +:ned:`PcpTrafficClassClassifier`. The priority assignment is determined by the +`transmissionSelection` submodule, which utilizes a :ned:`PriorityScheduler` configured +to operate in reverse order, i.e. priority increases with the +traffic class index. For example, in the provided image, video traffic takes +precedence over best effort traffic. + The Model --------- -There are three network nodes in the network. The client and the server are -:ned:`TsnDevice` modules, and the switch is a :ned:`TsnSwitch` module. The -links between them use 100 Mbps :ned:`EthernetLink` channels. +The Network ++++++++++++ + +We demonstrate the operation of CBS using a network containing a client, a server and a switch. +The client and the server (:ned:`TsnDevice`) +are connected through the switch (:ned:`TsnSwitch`), with 100Mbps Ethernet +links: .. figure:: media/Network.png :align: center -There are four applications in the network creating two independent data streams -between the client and the server. The data rate of both streams are ~48 Mbps at -the application level in the client. +Traffic ++++++++ + +In this simulation, we configure the client to generate two streams of +fluctuating traffic, which are assigned to two traffic categories. We insert +credit-based shapers for each category into the switch's outgoing interface +(``eth1``) to smooth traffic. + +Analogous to the Time-Aware Shaping showcase, our objective is to isolate and +observe the impact of the credit-based shaper on network traffic. To this end, +we aim for the traffic to be only modified significantly by the credit-based +shaper, avoiding any unintended traffic shaping effects elsewhere in the +network. To achieve this, we set up two traffic source applications in the +client, creating two separate data streams whose throughput varies sinusoidally +with maximum values of ~47 Mbps and ~34 Mbps, respectively. Given these +values, the network links are not operating at their full capacity, +thereby eliminating any significant traffic shaping effects resulting from link +saturation. Subsequently, we configure the traffic shaper to cap the data rates +of these streams at ~42 Mbps and ~21 Mbps, respectively. As a result, the +average incoming data rate is lower than the outgoing limit. Below are the +details of the traffic configuration: .. literalinclude:: ../omnetpp.ini :start-at: client applications :end-before: outgoing streams :language: ini -The two streams have two different traffic classes: best effort and video. The -bridging layer identifies the outgoing packets by their UDP destination port. -The client encodes and the switch decodes the streams using the IEEE 802.1Q PCP -field. +Traffic Shaping ++++++++++++++++ + +Within the client, our goal is to classify packets originating from the two +packet sources into two traffic classes: `best effort` and +`video`. To achieve this, we activate IEEE 802.1 stream +identification and stream encoding functionalities by setting the +:par:`hasOutgoingStreams` parameter in the switch to ``true``. We proceed by configuring the stream +identifier module within the bridging layer; this module is responsible for +associating outgoing packets with named streams based on their UDP destination +ports. Following this, the stream encoder sets the Priority Code Point (PCP) number on the packets according to +the assigned stream name (using the IEEE 802.1Q header's PCP field): .. literalinclude:: ../omnetpp.ini :start-at: outgoing streams :end-before: egress traffic shaping :language: ini -The traffic shaping takes place in the outgoing network interface of the switch -where both streams pass through. The traffic shaper limits the data rate of the -best effort stream to 40 Mbps and the data rate of the video stream to 20 Mbps. -The excess traffic is stored in the MAC layer subqueues of the corresponding -traffic class. +We enable egress traffic shaping in the switch, which +adds the time-aware shaper module to interfaces. In the time-aware shaper, we define two +traffic classes, and configure the transmission selection algorithm +submodules by setting their type to :ned:`Ieee8021qCreditBasedShaper`. This action +adds two credit-based shaper modules, one for each traffic class. We +then set the idle slope parameters of the two credit-based shapers to +~42 Mbps and ~21 Mbps, respectively: .. literalinclude:: ../omnetpp.ini :start-at: egress traffic shaping @@ -51,64 +155,120 @@ traffic class. Results ------- -The first diagram shows the data rate of the application level outgoing traffic -in the client. The data rate varies randomly over time for both traffic classes -but the averages are the same. +Let's take a look at how the traffic changes in and between the various network nodes. First, we +compare the data rate of the client application traffic with the shaper incoming +traffic for the two traffic categories: -.. figure:: media/ClientApplicationTraffic.png +.. figure:: media/client_shaper.png :align: center -The next diagram shows the data rate of the incoming traffic of the traffic -shapers. This data rate is measured inside the outgoing network interface of -the switch. This diagram is somewhat different from the previous one because -the traffic is already in the switch, and also because it is measured at a -different protocol level. +The client application and shaper incoming traffic is quite similar, but not identical. The shaper's incoming traffic +has a slightly higher data rate because of additional protocol overhead that +wasn't present in the application. Also, the two streams of packets are +combined in the client's network interface, which can cause some packets to be +delayed. Therefore, even if we adjusted for the extra protocol overhead, the traffic +wouldn't match exactly. + +Now let's examine how the traffic changes in the shaper by comparing the data +rate of the incoming and outgoing traffic: -.. figure:: media/TrafficShaperIncomingTraffic.png +.. figure:: media/shaper_both.png :align: center -The next diagram shows the data rate of the already shaped outgoing traffic of -the traffic shapers. This data rate is still measured inside the outgoing network -interface of the switch but at a different location. As it is quite apparent, -the randomly varying data rate of the incoming traffic is already transformed -here into a quite stable data rate. +On average, the data rate of the incoming traffic is below the shaper's limit, but there are intermittent periods when it exceeds the limit. +When this happens, the shaper +caps the data rate at the set limit, by storing packets temporarily +and then sending them out eventually, which smooths out the +outgoing traffic. When the data rate of the incoming traffic is below the +shaper's limit, traffic shaping isn't needed, and the outgoing traffic mirrors +the incoming traffic. + +.. note:: The data rate specified in the ini file as the idle slope parameter + corresponds to the channel data rate. However, the outgoing data rate inside the + shaper differs slightly due to protocol overhead, including factors like the PHY + (Physical Layer) and IFG (Interframe Gap). In this chart, we measure the data + rate within the shaper, so we have displayed the data rate limits as calculated + specifically for the shaper. -.. figure:: media/TrafficShaperOutgoingTraffic.png +The next chart compares the shaper outgoing and server application traffic: + +.. figure:: media/shaper_server.png :align: center -The next diagram shows the queue lengths of the traffic classes in the outgoing -network interface of the switch. The queue lengths increase over time because -the data rate of the incoming traffic of the traffic shapers is greater than -the data rate of the outgoing traffic, and packets are not dropped. +Much like the first chart, the shaper outgoing and server application traffic profiles are similar, but the shaper's +traffic is slightly higher due to protocol overhead. -.. figure:: media/TrafficShaperQueueLengths.png +Having examined the traffic across the entire network, we can conclude that the +traffic undergoes significant changes mainly within the shaper, while other +parts of the network remain unaffected by traffic shaping, consistent with our +expectations. + +The sequence chart below illustrates the transmission of frames within the +network. In this chart, the `best effort` traffic category is represented in +blue, while the `video category` is depicted in red. + +.. figure:: media/seqchart2.png :align: center -TODO +The traffic is bursty when it arrives in the switch. +The traffic shaper within the switch evenly distributes the packets and +interleaves video packets with those of the best effort category. -.. figure:: media/TransmittingStateAndGateStates.png +The next diagram illustrates the queue lengths of the traffic classes in +the switch's outgoing network interface. The queue lengths don't increase over +time, as the average data rate of the incoming traffic to the shaper is lower +than the permitted data rate for outgoing traffic. + +.. figure:: media/TrafficShaperQueueLengths.png :align: center -TODO +The following chart displays the rapid fluctuations in the number of credits. +The number can exceed zero when the corresponding queue is not empty. .. figure:: media/TrafficShaperNumberOfCredits.png :align: center -The next diagram shows the relationships between the number of credits, the gate -state of the credit based transmission selection algorithm, and the transmitting -state of the outgoing network interface for the both traffic classes. +The next chart provides a closer view of the chart shown above, with a zoomed-in perspective: -.. figure:: media/TrafficShaping.png +.. figure:: media/TrafficShaperNumberOfCredits_zoomed.png :align: center -The last diagram shows the data rate of the application level incoming traffic -in the server. The data rate is somewhat lower than the data rate of the -outgoing traffic of the corresponding traffic shaper. The reason is that they -are measured at different protocol layers. +The following chart illustrates the gate states for the two credit-based +shapers, as well as the transmitting state of the outgoing interface in the +switch. It is worth noting that the gates can remain open for longer durations +than a single packet transmission if the number of credits is zero or higher. +Additionally, the transmitter is not in a constant transmitting state since the +maximum outgoing data rate of the switch (~63Mbps) is lower than the channel +capacity (100Mbps). -.. figure:: media/ServerApplicationTraffic.png +.. figure:: media/TransmittingStateAndGateStates.png :align: center +The following diagram depicts the relationships among the number of credits, the +gate state of the credit-based transmission selection algorithm, and the +transmitting state of the outgoing network interface for both traffic classes. +To ensure visibility of the details, the diagram focuses on the first 2ms of the simulation: + +.. figure:: media/TrafficShaping.png + :align: center + +Note that the queue length remains at zero for most of the time since an +incoming packet can be transmitted immediately without causing the queue length +to increase to 1. Additionally, in the transmitter, there are instances where +two packets (each from a different traffic class) are transmitted consecutively, +with only an Interframe Gap period between them. For example, this can be +observed in the first two transmissions. It's important to highlight that such +back-to-back transmission of packets from different traffic classes does not +result in bursting within individual traffic classes. + +In this diagram, we can observe the operation of the credit-based shaper. +Let's consider the number of credits for the video traffic category as an +example. Initially, the number of credits is at 0. Then, when a packet arrives +at the queue and begins transmitting, the number of credits decreases. After the +transmission completes, the number of credits begins to increase again. As the +number of credits reaches 0 once more, another transmission starts, causing the +number of credits to decrease once again. + Sources: :download:`omnetpp.ini <../omnetpp.ini>` Discussion diff --git a/showcases/tsn/trafficshaping/creditbasedshaper/omnetpp.ini b/showcases/tsn/trafficshaping/creditbasedshaper/omnetpp.ini index b5de3206d1a..c9f2a93df0e 100644 --- a/showcases/tsn/trafficshaping/creditbasedshaper/omnetpp.ini +++ b/showcases/tsn/trafficshaping/creditbasedshaper/omnetpp.ini @@ -1,20 +1,22 @@ [General] network = inet.networks.tsn.TsnLinearNetwork -sim-time-limit = 1s +sim-time-limit = 10s +record-eventlog = false description = "Traffic shaping using credit-based shapers" #################### # Flow Configuration # -# Traffic class Packet interval Channel data rate Priority Shaping -# Best Effort 200us ~42.68Mbps 0 CBS -# Video 400us ~21.34Mbps 4 CBS +# Traffic class Packet interval CBS data rate Channel data rate Priority Shaping +# Best Effort 200us ~41.84Mbps ~42.64Mbps 0 CBS +# Video 400us ~20.92Mbps ~21.32Mbps 4 CBS # # Applicaion packet length: 1000B -# Credit based shaper packet lengt: 1042B = 1000B + 8B (UDP) + 20B (IP) + 14B (ETH MAC) -# Credit based shaper data rate: 1042B * 8 / Packet interval +# Credit based shaper packet lengt: 1046B = 1000B + 8B (UDP) + 20B (IP) + 14B (ETH MAC) + 4B (ETH FCS) +# Credit based shaper data rate: 1046B * 8 / Packet interval # Channel packet length: 1054B = 1000B (APP) + 8B (UDP) + 20B (IP) + 14B (ETH MAC) + 4B (ETH FCS) + 8B (ETH PHY) -# Channel data rate = (1054B + 12B (IFG) + 1B (cushion)) * 8 / Packet interval +# Channel data rate = (1054B + 12B (IFG)) * 8 / Packet interval +#################### # client applications *.client.numApps = 2 @@ -25,8 +27,8 @@ description = "Traffic shaping using credit-based shapers" *.client.app[0].io.destPort = 1000 *.client.app[1].io.destPort = 1001 *.client.app[*].source.packetLength = 1000B -*.client.app[0].source.productionInterval = exponential(200us) -*.client.app[1].source.productionInterval = exponential(400us) +*.client.app[0].source.productionInterval = replaceUnit(1 / (sin(dropUnit(simTime()) * 3) + 4.5), "ms") +*.client.app[1].source.productionInterval = replaceUnit(1 / (sin(dropUnit(simTime() * 1)) + sin(dropUnit(simTime() * 8)) + 2), "ms") # server applications *.server.numApps = 2 @@ -54,9 +56,9 @@ description = "Traffic shaping using credit-based shapers" *.switch.bridging.directionReverser.reverser.excludeEncapsulationProtocols = ["ieee8021qctag"] # credit based traffic shaping -*.switch.eth[*].macLayer.queue.numTrafficClasses = 2 -*.switch.eth[*].macLayer.queue.*[0].display-name = "best effort" -*.switch.eth[*].macLayer.queue.*[1].display-name = "video" -*.switch.eth[*].macLayer.queue.transmissionSelectionAlgorithm[*].typename = "Ieee8021qCreditBasedShaper" -*.switch.eth[*].macLayer.queue.transmissionSelectionAlgorithm[0].idleSlope = 42.68Mbps # Channel data rate -*.switch.eth[*].macLayer.queue.transmissionSelectionAlgorithm[1].idleSlope = 21.34Mbps # Channel data rate +*.switch.eth[1].macLayer.queue.numTrafficClasses = 2 +*.switch.eth[1].macLayer.queue.*[0].display-name = "best effort" +*.switch.eth[1].macLayer.queue.*[1].display-name = "video" +*.switch.eth[1].macLayer.queue.transmissionSelectionAlgorithm[*].typename = "Ieee8021qCreditBasedShaper" +*.switch.eth[1].macLayer.queue.transmissionSelectionAlgorithm[0].idleSlope = 42.64Mbps # Channel data rate +*.switch.eth[1].macLayer.queue.transmissionSelectionAlgorithm[1].idleSlope = 21.32Mbps # Channel data rate