The device is dropping 64-byte frames when pushing traffic at 10G. This is a Point-to-Point circuit. MX on the one side is an MX960, and the other side is a MX480.

Customer observes that traffic (when specifically set to 64 bytes ONLY) begins to drop and limits BW to ~8G during testing.

RED drops are seen on the COS Queue in the customer environment and the Queue-Depth is max utilized.

Queue: 6, Forwarding classes: FC_MGMT, FC_SPECTRUM-GOLD

 Queued:

  Packets       :      1155219356       12074336 pps

  Bytes        :      97038425904      8113954176 bps

 Transmitted:

  Packets       :      1125068124       11648188 pps

  Bytes        :      94505722416      7827582464 bps

  Tail-dropped packets :           0           0 pps

  RL-dropped packets  :           0           0 pps

  RL-dropped bytes   :           0           0 bps

  RED-dropped packets :       30151232        426148 pps

   Low         :       30151232        426148 pps

   Medium-low     :           0           0 pps

   Medium-high     :           0           0 pps

   High        :           0           0 pps

  RED-dropped bytes  :      2532703488       286371712 bps

   Low         :      2532703488       286371712 bps

   Medium-low     :           0           0 bps

   Medium-high     :           0           0 bps

   High        :           0           0 bps

 Queue-depth bytes   : 

  Average       :       20445952

  Current       :       20460310

  Peak         :       20476120

  Maximum       :       20840448

RFC2544 performance testing for 64 Byte packets.

What happened?

During testing, there were extremely small packets sent through your router to measure its performance. These tiny packets arrive at a very high rate—far faster than normal Internet traffic.

Why does this matter?

The router can easily handle full-speed 10G traffic, but the unusually high number of packets per second briefly filled its internal queue. When this happens, the router intentionally drops low-priority test packets to prevent any impact on normal traffic.

Is this a problem?

No. This behavior is expected during synthetic tests that use packets of the minimum size. With normal-sized packets—like those used for real customer applications—no drops occur.

What does this mean for the customer?

Your network is performing normally. The packet drops were limited to the artificial test scenario and do not indicate any issue with your service.

=============================

3. Queue Behavior Diagrams

=============================

Packet Processing at Normal Packet Sizes

Traffic Rate: Moderate PPS

--------------------------------------

Ingress ---> [Queue] ---> Egress

             [30%]       

             [Full]       

--------------------------------------

Result: Queue stays mostly empty → No drops

S

Behavior Under 64-Byte Packet Testing

Traffic Rate: Extremely High PPS (~12.6Mpps)

---------------------------------------------------

Ingress ---> [Queue] ---> Egress

          [98–100% Occupied]   

             [ RED Active] 

---------------------------------------------------

Result: High queue occupancy triggers RED → Low-priority packets dropped early

Standards

Ethernet Timing and Frame Sizes

• IEEE 802.3-2018, Clause 3 – Defines minimum Ethernet frame size (64 bytes).
• Preamble + SFD (Start Frame Delimiter): 8 bytes
• IEEE 802.3, Clause 3.3
• Inter-Frame Gap (IFG): 96 bit-times (12 bytes)
• IEEE 802.3, Clause 4.2.3.2.4
• On-wire size for a 64-byte frame:
• 64B (frame) + 8B (preamble/SFD) + 12B (IFG) = 84 bytes

Packet Rate Limits

• Theoretical PPS at 10G with minimum frames:
• 10,000,000,000 bps ÷ 672 bits/frame ≈ 14.88 Mpps
• (Industry standard, derived from IEEE-defined timing intervals.)
• Testing at 8.5 Gbps yields:
• 8.5 Gbps ÷ 672 bits = 12.65 Mpps