VIAVI TestCenter: Why does RFC-3918 mixed class throughput intended load does not match the expected load?

VIAVI TestCenter: Why does RFC-3918 mixed class throughput intended load does not match the expected load?

• Intended load is a measure of load on the INGRESS ports.  • Since multicast traffic is replicated by the DUT the intended load DOES NOT EQUAL the actual load coming out of the DUT (egress). • Some key points of RFC-3918 Mixed Class Throughput • https://datatracker.ietf.org/doc/html/rfc3918#section-4.1 • Looking at the Objectives and Procedure, it indicates: • The multicast and unicast are offered simultaneously and are mixed together in same aggregated traffic stream. • The intended load SHOULD be configured as alternating  multicast class frames and unicast class frames to a single ingress interface. • This tells me the Mixed traffic should be coming from the same source port. • See below Examples 1 and 2 • In Example 1, both ingress and egress can be tested for maximum mixed class traffic. • In Example 2, this seems to only stress the DUT ingress since there are multiple egress ports, which means the unicast traffic will be split among the egress and thus will have lower rates. • Example #3 (multiple Tx ports) appears to be outside the scope of the RFC-3918 specs but VIAVI allows for it. • This can be used to test the DUT egress ports for MAX mixed class. • Examples: • Example 1 - 1 Tx port to 1 Rx port • Port 1 sends 100% Mixed Class and results will show 100% Mixed Class  (10% mcast and 90% unicast to Port 2) • Port 2 receives 100% load of Mixed Class • Example 2 - 1 Tx port to 2 Rx ports • Port 1 sends 100% Mixed Class and results will show 100% Mixed Class • (10% mcast and 45% unicast to Port 2 and 45% unicast to Port 3) Note that results will show a combined value, 10% mcast and 90% unicast • Port 2 receives 55% load of Mixed Class (10 + 45) • Port 3 receives 55% load of Mixed Class (10 + 45) • Example 3 - 3 Tx ports and 2 Rx ports (100% Mixed on Egress with multiple Rx ports but results will show 63.33%) • Port 1 sends 10% Multicast • Port 2 sends 90% Unicast to Port 3 • Port 3 sends 90% Unicast to Port 2 • Port 2 received 100% Mixed Class (10 + 90) • Port 3 received 100% Mixed Class (10 + 90) • (Mixed Class % is calculated on the number of Tx ports) • Port 1 = 10/100 • Port 2 = 90/100 • Port 3 = 90/100 • Total 190/300 = 63.33% Mixed Class • So it depends on what you would like to test. • 100% Mixed Class on the DUT Ingress, Port 1 transmitting both 100% of combined Multicast and Unicast into the DUT. • or • 100% Mixed Class on the DUT Egress, Port 2 and 3 will receive 100% combined Multicast and Unicast from the DUT. • (note the only way for Port 2 and 3 can receive 100% is by having multiple transmit ports as in Example 3 but as mentioned in example 3, the Mixed Class displayed percentage will not show 100% and you will have to look at the separate multicast and unicast columns then add it to get 100%) •   Additional examples and thoughts: • For example, consider a 4 port test where you have 1 port transmitting multicast traffic to 3 receivers and those 3 receivers are sending full-mesh traffic to each other. • Furthermore, let’s use a 9:1 multicast : unicast ratio. • Port 1 is transmitting multicast at 90% load (90% to Port 2,3, and 4) • Port 2 is transmitting unicast at 10% load (5% to Port 3 and 5% to Port 4) • Port 3 is transmitting unicast at 10% load (5% to Port 4 and 5% to Port 2) • Port 4 is transmitting unicast at 10% load (5% to Port 2 and 5% to port 3) • The intended load in this case is… • Multicast intended load + unicast intended load = 90/400 + 30/400 = 120/400 = 30% intended load • However, on Ports 2,3, and 4, if we had a perfect DUT we would expect 100% load on each EGRESS port, since each port should be forwarding 90% multicast and 10% unicast. • Anyway, for the 3918 mixed class throughput test, the intended load is not very useful in determining the actual load on the DUT, as intended load and actual forwarded traffic don’t have a 1:1 relation. • We can also think of it this way: • The intended load on the ingress will be the multicast : unicast ratio that will be exiting the DUT egress port. • So if we say we have 1 Src and 3 Dst ports and the intended load is set to 100% with a 4:1 ratio (80% multicast : 20% unicast) • To full fill the 100% intended load on the ingress with a ratio of 4:1 for each egress port we need 57.143% of Multicast and 42.857% of Unicast • To verify the 4:1 ratio on the egress it would be 42.847 / 3 = 14.286, so the 4:1 ratio is 57.143 : 14.286. • How we got 57.143% and 14.286% • 4:1 ratio with 1 src (x) and 3 dst (y) at 100% • equations: x=4y, x=100-3y • 4y=100-3y • 7y=100, y=100/7, y=14.286 • Depending upon the topology the intended load may never reach 100% • Example is if you have 2 Src ports but one is strictly Multicast and the other is strictly Unicast. • If we keep the 4:1 ratio on egress we can sustain on the Sources 80% Multicast and 60% Unicast. • The 60% would be divided by 3 which is 20%, thus the 80/20 (4:1) ratio on the egress. • The Mixed Class intended load would be 70% due to the combination of 80 / 60. • Because TestCenter allows some unconventional configurations by customer it will give results according to that configuration. • Here is an interesting example: • Results show Mixed Class 90%, Multicast 12%, Unicast 88% • Config is 1:4 multicast to unicast ratio • Topology has 12 total ports. Port 1 is the source and Ports 2-12 are clients. • Unicast - Port 1 sending to Port 7. Port 2 to 8, Port 3 to 9, Port 4 to 10, Port 5 to 11, Port 6 to 12 • This is a perfect example of RFC 3918’s specification is under-specified. • Basically, there is no term or measurement for the load you expect on the *output* ports.  • Internally, the TestCenter test looks at the topology being used and the multicast/unicast ratio and calibrates 100% to whatever input load generates maximal egress load *without* overloading any egress ports.  • So, that’s why “100%" generates this particular load (ports 7-12 should receive maximal egress load).  • Basically, it tries to satisfy all the constraints given to it by the user, but wacky configurations like this example tend to be a little quirky. • Anyway, you have Ports 1-6 transmitting unicast at 88% load, so ports 7-12 should be receiving 88% unicast traffic.  Clearly this is 88% load. • Port 1 is also transmitting multicast traffic at 12% load, so we expect 12% load on ports 2 – 12.  Clearly, this is 12% load. • For the mixed class case, we have to look at all of the ports in the test. • So, ports 2-6 are receiving 12% total traffic, all multicast.  Ports 7-12 are receiving 100% traffic, where 12% is multicast and 88% is unicast. (12% * 11 ports + 88% * 6 ports) / (11 ports) = 60% load.  • Because of this unconventional config the template simply shows the loads aren’t additive. Meaning although 12% + 88% = 100%, the mixed class will not be represented as 100%. • The results would make a lot more sense if only ports 7-12 were receiving multicast traffic.  Or, if ports 1-11 were generating full-mesh unicast. • The 1:4 ratio • 12% * 11 ports = 132% multicast • 88% * 6 ports = 528% unicast • 528/132 = 4 • If the load generation logic of the test cannot figure out a solution to the problem that maintains the correct load relationship between multicast and unicast, it will generate an error.