Hubbry Logo
Out-of-order deliveryOut-of-order deliveryMain
Open search
Out-of-order delivery
Community hub
Out-of-order delivery
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Out-of-order delivery
Out-of-order delivery
Out-of-order delivery
View on Wikipedia
from Wikipedia

In computer networking, out-of-order delivery is the delivery of data packets in a different order from which they were sent. Out-of-order delivery can be caused by packets following multiple paths through a network, by lower-layer retransmission procedures (such as automatic repeat request), or via parallel processing paths within network equipment that are not designed to ensure that packet ordering is preserved. One of the functions of TCP is to prevent the out-of-order delivery of data, either by reassembling packets in order or requesting retransmission of out-of-order packets.

See also

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Out-of-order delivery

View on Grokipedia
from Grokipedia
Out-of-order delivery, in the context of computer networking, occurs when data packets arrive at their destination in a different sequence than the order in which they were originally sent, violating the expected monotonic increase in sequence numbers. This phenomenon arises in IP-based networks, which provide without guarantees of packet ordering, as packets may take multiple paths with varying delays or be processed in parallel. Common causes include route changes leading to differing path lengths, load balancing across links, layer-2 retransmissions, or buffer management issues in routers. The effects of out-of-order delivery can degrade , particularly for transport protocols like TCP, which interpret significant reordering as potential , triggering unnecessary retransmissions and reducing throughput. For instance, TCP's default duplicate acknowledgment threshold of three can cause premature fast retransmit if packets are reordered beyond this limit, leading to congestion window reductions. In contrast, UDP does not inherently reorder packets but delivers them as received, leaving reassembly to the , which may result in errors for time-sensitive applications like voice or video streaming if buffering is insufficient. Metrics such as the reordered packet ratio (total reordered packets divided by total received) and reordering extent (the maximum gap in sequence numbers) are used to quantify and evaluate the severity of reordering in network paths. To mitigate out-of-order delivery, receivers employ reordering buffers to hold early-arriving packets until their predecessors arrive, though buffer size and delay limits constrain effectiveness. Extensions like TCP SACK (Selective Acknowledgment) and D-SACK help distinguish reordering from loss, improving robustness, while protocols such as Deterministic Networking (DetNet) incorporate packet ordering functions for applications requiring strict sequencing. Overall, while minor reordering is common and often tolerable, excessive instances highlight underlying network inefficiencies that can impact reliability across diverse applications.

Overview

Definition

Out-of-order delivery in computer networking refers to the phenomenon where data packets arrive at the destination host in a sequence different from the order in which they were transmitted by the source host, particularly within IP-based networks that operate on a model. The (IP) does not provide any guarantees regarding packet ordering, as it treats packets independently and routes them through potentially diverse paths, leading to possible reordering without inherent mechanisms to enforce sequential arrival. This contrasts with , where packets fail to arrive entirely, or duplication, where identical packets are received multiple times; out-of-order delivery involves all packets reaching the destination but in an incorrect sequence. A simple illustration of out-of-order delivery occurs when three consecutively numbered packets—labeled 1, 2, and 3—are sent in that order from the source but arrive at the destination as 1, 3, then 2, due to varying network delays or paths taken by each packet. To detect and manage such disorder, transport-layer protocols commonly employ sequence numbers assigned to packets or their constituent data units, allowing the receiver to identify deviations from the expected order and reassemble the original sequence. In the TCP/IP protocol stack, out-of-order delivery is a challenge addressed primarily at the , where protocols like TCP use sequence numbers to ensure reliable, ordered data delivery to applications despite the underlying IP layer's lack of ordering guarantees.

Historical context

The concept of out-of-order packet delivery became prominent with the development of protocols in the late 1970s, building on the foundations of early packet-switched networks like the (1969–1990). While ARPANET's initial Network Control Protocol (NCP), deployed from 1970 to 1983, supported host-to-host communication and relied on the network's Interface Message Processors for reliable, in-order delivery, the introduction of the marked a shift to connectionless, across heterogeneous systems. RFC 791, published in 1981, explicitly defined IP as a connectionless protocol that provides no guarantees for packet ordering, allowing datagrams to arrive in any sequence or not at all due to the decentralized nature of the internetwork. To mitigate this, the companion Transmission Control Protocol (TCP) specification in RFC 793, also from 1981, introduced sequence numbers and reassembly mechanisms, enabling receivers to reorder packets and reconstruct the original stream despite potential disorder introduced by the underlying IP layer. Subsequent IETF discussions in the 2000s further highlighted out-of-order delivery in congested environments, as noted in RFC 3366 (2002), which advised link designers on minimizing reordering in (ARQ) protocols to avoid exacerbating and throughput issues in IP flows. The gained increased visibility as a practical challenge with the widespread adoption of Equal-Cost Multi-Path (ECMP) in the 1990s, where traffic load balancing across equal-cost paths inherently risked reordering due to differential latencies. In more recent milestones, multipath capabilities in networks, as specified in TS 38.300 (2023), and the protocol's multipath extensions (draft-ietf-quic-multipath, ongoing), have amplified the issue by leveraging multiple simultaneous paths for resilience and throughput, necessitating advanced handling at higher layers.

Causes

Network routing factors

Network routing factors play a significant role in out-of-order delivery, primarily through mechanisms that distribute traffic across multiple paths with varying latencies. Equal-Cost Multi-Path (ECMP) routing, commonly used in modern networks to balance load, selects paths of equal metric cost by hashing packet headers, such as the 5-tuple for flows. While standard ECMP implementations keep packets from the same flow on a single path to avoid reordering, variations or misconfigurations that split flow packets across paths can lead to different transit times due to queueing differences or link speeds, resulting in reordering. Load balancing in routers and switches often employs hash-based distribution to spread , but when configured for per-packet rather than per-flow balancing, sequential packets may follow uneven paths with disparate delays. This , typically based on source/destination addresses or ports, can direct consecutive packets to links with varying congestion levels, exacerbating reordering especially in high-throughput environments. Such practices, though less common due to their impact on transport protocols, are noted in enterprise and setups for maximizing utilization. Asymmetric routing, where forward and return paths differ, further contributes to reordering in bidirectional flows, as packets in one direction may traverse faster routes while the reverse takes longer paths influenced by arrangements. This is prevalent in the due to policy-based routing decisions by autonomous systems. In backbone networks, interactions between points and transit providers amplify this; for instance, at exchange points like , parallel components such as hunt groups and high traffic volumes led to frequent reordering observed in end-to-end measurements. In modern wireless networks, such as and emerging systems, frequent handovers due to high-speed mobility (e.g., in vehicular networks) can cause reordering as packets switch between base stations or paths mid-flow. Quantitatively, reordering probability escalates with path diversity; in Internet-scale tests near major backbones, over 90% of paths exhibited reordering for probe packets, with only a small fraction arriving in strict order. In fabric topologies employing ECMP, path multiplicity (e.g., multiple equal-cost routes in Clos networks) can increase reordering rates significantly under packet spraying variants, though standard per-flow hashing mitigates this within individual flows. These factors highlight how infrastructure inherently introduces variability in packet arrival order.

Device processing factors

In multi-core routers, parallel processing of packets across multiple cores can lead to out-of-order delivery due to variations in processing times and queue depths among cores. When packets from the same flow are assigned to different cores for handling, disparities in workload, cache efficiency, or queue management can cause later packets to complete processing and depart before earlier ones, disrupting sequence. For instance, dynamic core allocation schemes in network processors aim to mitigate this by balancing loads, but inherent variations in queue depths—such as deeper queues on busier cores delaying dequeued packets—still contribute to reordering in high-throughput environments. Interrupt coalescing in network interface cards (NICs) and switches introduces delays that exacerbate out-of-order arrivals by batching multiple packets before generating a single to the host CPU. This mechanism reduces CPU overhead in high-bandwidth scenarios by waiting for a or packet threshold, but it can allow subsequent packets to arrive and be processed faster if they bypass the coalescing delay, earlier batched ones. Studies show that such coalescing alters packet inter-arrival times, leading to reordering metrics like reorder increasing under bursty traffic, particularly when combined with variable buffering in device pipelines. Quality of Service (QoS) scheduling mechanisms in devices prioritize packets based on traffic classes, intentionally reordering them to favor latency-sensitive flows like data, which can result in out-of-order delivery for non-prioritized streams. Devices employ multiple queues with strict priority or , where high-priority packets (e.g., VoIP) are dequeued and forwarded ahead of lower-priority ones from the same flow, causing sequence disruptions downstream. This reordering is a deliberate trade-off for guarantees, but it increases the reordering extent in mixed-traffic networks, as measured by buffer-occupancy density in affected flows. Hardware offloading features, such as TCP Segmentation Offload (TSO) and Receive Side Scaling (), contribute to out-of-order delivery by generating bursty transmissions or uneven flow distribution across receive queues. TSO allows the NIC to segment large TCP payloads into multiple packets, but variations in segmentation timing or host buffering can lead to bursts where later segments arrive out of sequence relative to prior flows. Similarly, hashes packet flows to distribute them across multiple CPU cores and queues for parallel processing, but hash collisions or uneven load balancing can cause packets from the same flow to be processed at different speeds, resulting in reordering upon reassembly. Proper tuning of indirection tables is essential to minimize this, as out-of-order arrivals can degrade TCP throughput by triggering unnecessary retransmissions. In firewalls and Intrusion Prevention System (IPS) devices, (DPI) processes packets unevenly by holding them in reorder buffers during stateful analysis, allowing faster non-inspected or lightly inspected packets to overtake those undergoing thorough scrutiny. requires reassembly of TCP streams to inspect content, and if out-of-order packets arrive, the device buffers them until the full sequence is complete, but incomplete reassembly or buffer overflows can release packets in altered order. implementations, for example, support configurable out-of-order packet caching in zone-based firewalls to handle this, preventing drops but still permitting reordering in high-volume inspections.

Protocol handling

TCP mechanisms

TCP employs 32-bit sequence numbers in its header to uniquely identify and order segments, enabling the receiver to detect and reassemble out-of-order packets. These sequence numbers, ranging from 0 to 2^{32}-1 with , are assigned to each byte of transmitted, allowing the sender to track progress with variables like SND.NXT (next sequence number to send) and the receiver to expect order via RCV.NXT (next expected sequence number). A segment is considered acceptable if its sequence number falls within the receive window, defined as RCV.NXT to RCV.NXT + RCV.WND - 1, where RCV.WND is the advertised receive window size. On the receiver side, out-of-order packets are buffered in a reassembly queue until the missing segments arrive, ensuring is delivered to the application in the correct sequence. The receiver queues segments that are within the window but not contiguous with RCV.NXT, holding them for later processing once gaps are filled. This buffering prevents premature delivery of disordered , maintaining TCP's reliability guarantee, though it requires sufficient allocation for the reassembly buffer. To detect losses causing out-of-order arrivals, TCP uses duplicate acknowledgments (ACKs), where the receiver sends an ACK for the last in-order segment upon receiving an out-of-order one, signaling a "" in the sequence. Upon receiving three such duplicate ACKs—indicating a missing segment without intervening packets—the sender triggers the fast retransmit algorithm, retransmitting the presumed lost segment immediately without waiting for the retransmission timer. This selective retransmission targets only the gap, allowing continued transmission of new data and improving efficiency over timeout-based recovery. The Selective Acknowledgment (SACK) extension, defined in RFC 2018 (1996), enhances this by permitting the receiver to report multiple non-contiguous blocks of successfully received beyond the cumulative ACK. SACK options include up to four blocks, each defined by left and right edge sequence numbers, enabling the sender to retransmit only truly missing segments rather than assuming all data after the gap is lost. This optimizes recovery from multiple losses or significant reordering, reducing unnecessary retransmissions and improving throughput in reordered environments. The Duplicate Selective Acknowledgment (D-SACK) extension, defined in RFC 2883 (2000), builds on SACK by using the first SACK block to report receipt of duplicate segments. This allows the sender to detect cases where fast retransmit was triggered by reordering rather than loss—for example, when a delayed original packet arrives after its retransmission—avoiding erroneous congestion control responses like unnecessary reductions. Window scaling, introduced in RFC 1323, addresses limitations in handling large reordering by expanding the 16-bit field to an effective 32-bit size via a shift factor (up to 14 bits, yielding windows up to 1 GB), which is negotiated during connection setup. This larger receive allows buffering more out-of-order packets—up to the scaled RCV.WND size—before discarding due to , though standard SACK limits reporting to four blocks, constraining recovery for extreme reordering. The 32-bit fundamentally limits the effective to half the space (2^{31} bytes) to distinguish new data from wrapped-around duplicates, providing a basic bound on tolerable reordering without advanced extensions.

UDP and other protocols

Unlike TCP, which enforces in-order delivery through sequence numbers and retransmissions, operates as a connectionless transport protocol without any built-in sequencing or reordering mechanisms. UDP simply delivers datagrams to the in the order they are received by the receiving host, which can result in out-of-order arrival if packets take different network paths or experience varying delays. This design choice prioritizes low latency and minimal overhead, making UDP suitable for applications where occasional out-of-order packets are tolerable or can be handled at the application level. The responsibility for managing out-of-order delivery in UDP-based systems falls to the overlying application protocols. For instance, the (RTP), commonly used over UDP for , incorporates a 16-bit sequence number in each packet header to allow receivers to detect and reorder or discard out-of-order packets, ensuring synchronized playback despite network . Similarly, applications like DNS or VoIP may implement custom buffering or ignore ordering for non-critical data, but for order-sensitive scenarios, developers must add explicit sequencing logic to reassemble payloads correctly. The protocol, defined in RFC 9000, addresses out-of-order delivery more robustly while building on UDP's foundation to support reliable, multiplexed connections. QUIC uses monotonically increasing packet numbers for ordering, combined with acknowledgment (ACK) frames that include ranges of received packet numbers, enabling explicit detection and handling of reorders without across streams. This mechanism, particularly useful in multipath environments like mobile networks, allows QUIC to tolerate packet reordering by delaying ACKs until gaps are filled or using provisional ACKs for reordered packets. Other protocols layered over UDP or similar transports exhibit varied approaches to out-of-order delivery. The (SCTP) supports multi-streaming, where each stream maintains independent partial ordering—delivering data within a stream in sequence but allowing inter-stream reordering to avoid blocking—via stream identifiers and per-stream sequence numbers. In contrast, encapsulation in tunnels can exacerbate reordering by introducing additional processing delays or path variations, potentially fragmenting or delaying packets without native correction, requiring upper-layer protocols to compensate. These protocols highlight a key : UDP's simplicity and lower overhead facilitate faster initial delivery and reduced CPU usage compared to ordered protocols, but it shifts the burden of reordering to applications, which must implement corrections for in scenarios like real-time communication or file transfers. This app-level flexibility enables tailored handling but increases development complexity for reliability.

Impacts

Performance degradation

Out-of-order packet delivery in TCP leads to head-of-line (HOL) blocking, where the receiver must wait for a missing packet before processing subsequent out-of-order packets, thereby stalling data delivery and reducing effective throughput. This mechanism ensures in-order delivery but introduces inefficiencies, as buffered packets remain idle until the gap is filled via retransmission or late arrival. The phenomenon exacerbates latency at the , with buffering and subsequent retransmissions adding delays that can reach hundreds of milliseconds in scenarios involving persistent reordering or timeouts. For instance, in high-speed networks, reordering can extend the effective round-trip time by forcing TCP into recovery modes, where the time until a missing packet is detected and retransmitted—often governed by duplicate acknowledgments or timers—compounds the initial disorder. Empirical simulations indicate average reordering delay times equivalent to 1-2 packet intervals at rates above 100 Mbps, scaling with network load. Bandwidth inefficiency arises from the overhead of handling reordering, including the generation of duplicate acknowledgments (DUPACKs) to signal gaps and selective retransmissions of only missing segments, which consume additional network resources without advancing useful data transfer. This overhead can trigger spurious congestion control invocations, as TCP misinterprets reordering as loss, leading to unnecessary window reductions. Key metrics for quantifying out-of-order delivery include the reorder ratio, defined as the percentage of packets arriving out of sequence relative to the total packets in a flow, and the reordering extent, which measures the maximum displacement or gap size (e.g., number of positions a packet is reordered). These metrics help assess severity; even low reorder ratios can lead to noticeable TCP disruptions. Empirical studies of backbones reveal reorder ratios typically ranging from 0.3% to 2%, with occasional peaks up to 1.65% in high-load UDP flows, leading to significant TCP throughput reductions in affected sessions due to repeated fast retransmits and window halving. In simulated high-speed environments mimicking backbone conditions, even low reordering (e.g., 0.04% affecting events) can reduce throughput from hundreds of Mbps to below 10 Mbps for standard TCP variants.

Application-level effects

Out-of-order delivery of packets can significantly disrupt real-time applications that rely on timely and sequential data arrival, such as (VoIP) systems. In VoIP, reordered audio packets lead to , causing garbled sound, clipping, and dropped audio bits, which degrade call quality and . For instance, when packets containing sequential audio samples arrive out of sequence, the receiver may play incomplete or incorrect segments, resulting in audible distortions that become perceptible even at low reordering rates. Video streaming protocols like (HLS) and (DASH) are similarly affected, where out-of-order packets contribute to frame drops and playback interruptions. Reordered video packets can cause visual artifacts, such as frozen frames or desynchronized audio-video sync, reducing the overall (QoE) as the decoder struggles to reconstruct the stream correctly. Studies have shown that packet reordering due to network traffic directly lowers perceived video , with users reporting noticeable degradation in smoothness and clarity. In UDP-based multiplayer games, out-of-order delivery exacerbates position glitches and issues among players. Game state updates, such as player movements or actions, arriving out of sequence can lead to inconsistent world views, causing erratic behavior like teleporting characters or mismatched collisions, which frustrate users and disrupt flow. Since UDP provides no inherent reordering, applications must implement custom sequencing to mitigate these effects, but persistent reordering still introduces latency in reconciling the state. Bulk transfer applications, such as FTP or HTTP downloads, experience less noticeable impacts from out-of-order delivery due to TCP's built-in reordering mechanisms at the . While reordering may trigger temporary buffering and retransmissions, slowing overall throughput, the effects are typically imperceptible to users as the protocol reassembles data before application delivery, prioritizing reliability over immediacy. Modern protocols like can also suffer from reordering, interpreting it as loss and reducing performance compared to TCP in some cases. To counteract these issues, applications often employ buffering strategies to reorder packets, trading increased latency for improved smoothness. Many media players use jitter buffers ranging from tens of milliseconds to several seconds, allowing time for delayed or reordered packets to arrive before playback. In WebRTC-based video calls, the NetEQ jitter buffer handles reordering by temporarily storing packets and reassembling them, but excessive reordering increases and can lead to perceptible quality loss, with user satisfaction declining as reorder rates rise.

Detection and mitigation

Measurement techniques

Passive monitoring techniques involve capturing network traffic and analyzing packet sequence numbers to identify reordering events without injecting additional traffic. Tools such as and are commonly used for this purpose. 's TCP analysis feature tracks session states and flags packets as "TCP Out-Of-Order" when a packet arrives with a sequence number that does not follow the expected order, allowing users to quantify reordering by filtering and counting such events in capture files. Similarly, captures raw packets, after which scripts or post-processing tools like tshark (Wireshark's command-line variant) can parse sequence numbers to detect and measure reordering ratios in TCP flows. These methods are effective for real-world but may be influenced by protocol-specific behaviors, such as TCP retransmissions, requiring careful interpretation to distinguish true reordering from other anomalies. Active probing methods send controlled probe packets to measure reordering directly, providing quantifiable metrics under specific conditions. ICMP echo requests and replies, as well as UDP probes, are standard for this; for instance, sending bursts of ICMP pings or UDP packets with embedded sequence numbers allows calculation of the reorder percentage by comparing send and receive orders at the endpoint. These probes can also capture associated delays, revealing the extent of reordering, such as the number of positions a packet is displaced. Bennett et al. demonstrated that over 90% of probe bursts exhibited reordering using ICMP, though results vary by path and must account for potential ICMP filtering in networks. Key metrics for quantifying out-of-order delivery include the Reorder Free Ratio, which measures the proportion of packets arriving in sequence without reordering, and the Duplicate Tolerance parameter from the Performance Metrics (IPPM) framework, which accounts for allowable duplicates in reordering assessments to avoid false positives from retransmissions. Inter-packet arrival time variance serves as an indirect indicator, where increased variability in arrival times between consecutive packets signals potential reordering events disrupting expected timing. The required reorder buffer size, often derived from the Reorder Buffer-Occupancy Density (RBD), estimates the maximum number of packets a receiver must buffer to restore order, helping evaluate network tolerance thresholds. For controlled environments, in UDP mode sends sequenced probes and reports out-of-order packet counts directly in its output, enabling precise measurement of reordering percentages during bandwidth tests. These tools align with IPPM standards, such as RFC 4737 from the IETF's IPPM working group (2006), which formalizes reordering metrics including tolerance for duplicates to ensure robust evaluations.

Strategies to reduce occurrence

Several strategies exist to minimize out-of-order packet delivery in networks, focusing on routing configurations, device settings, overall architecture, protocol optimizations, and hardware capabilities. These approaches aim to ensure that packets within the same flow follow consistent paths or are processed in a manner that preserves sequence, thereby reducing reordering incidents without relying on extensive application-level corrections. Flow-based hashing in Equal-Cost Multi-Path (ECMP) routing is a key method to direct all packets of the same flow along the identical network path. By computing a hash using the 5-tuple—source and destination IP addresses, source and destination ports, and protocol type—routers assign consistent forwarding decisions, preventing the that leads to reordering in per-packet load balancing. This technique is widely implemented in modern routers to maintain order while achieving load distribution across multiple paths. In environments sensitive to reordering, such as real-time applications, disabling parallel processing features like Receive Side Scaling () and TCP Segmentation Offload (TSO) on network interfaces can help. RSS distributes incoming packets across multiple CPU cores using flow hashing, but misconfigurations or hardware limitations may occasionally disrupt order; similarly, TSO segments large TCP payloads in the NIC, potentially causing inconsistencies when combined with other network elements like firewalls. Turning these off forces sequential processing on a single core or without offload, eliminating such risks at the cost of reduced throughput. Network design plays a crucial role in avoiding reordering by enforcing symmetric paths and structured forwarding. Asymmetric , where inbound and outbound take different routes, often results in packets arriving out of due to varying latencies; implementing symmetric path policies through route symmetry checks or BGP attributes mitigates this. Additionally, (MPLS) provides strict ordering by labeling packets for deterministic paths in label-switched networks, bypassing variability and ensuring in-order delivery, particularly in backbones. Protocol enhancements in TCP further reduce the impact of minor reordering by improving recovery mechanisms. Enabling Selective Acknowledgment (SACK), as defined in RFC 2018, allows receivers to acknowledge non-contiguous byte ranges, enabling senders to retransmit only missing segments rather than assuming losses from gaps caused by reordering. Similarly, TCP timestamps (RFC 1323) provide precise sequencing information, aiding in duplicate detection and accurate reassembly even when packets arrive slightly out of order, thus tolerating low-level disruptions without performance penalties. Hardware solutions, such as switches supporting per-flow queuing, offer fine-grained control to preserve order at the device level. These switches maintain separate queues for individual flows, preventing where a delayed packet in one flow stalls others; instead, each flow's packets are buffered and dequeued in sequence. This is particularly effective in (TSN) environments, where dynamic allocation of queues per flow ensures low reordering delays across high-speed links.

References

  1. https://datatracker.ietf.org/doc/html/rfc4737
  2. https://www.cs.princeton.edu/courses/archive/fall16/cos318/lectures/21.InterNetworking.pdf
  3. https://datatracker.ietf.org/doc/html/rfc2018
  4. https://datatracker.ietf.org/doc/html/rfc2883
  5. https://datatracker.ietf.org/doc/html/rfc8655
  6. https://datatracker.ietf.org/doc/html/rfc5236
  7. https://www.rfc-editor.org/rfc/rfc5236.html
  8. https://www.rfc-editor.org/rfc/rfc791.html
  9. https://www.noction.com/blog/equal-cost-multipath-ecmp
  10. https://www.etsi.org/deliver/etsi_ts/138300_138399/138300/18.05.00_60/ts_138300v180500p.pdf
  11. https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/
  12. https://dl.acm.org/doi/10.1145/1851182.1851206
  13. https://datatracker.ietf.org/doc/html/rfc3449
  14. https://dl.acm.org/doi/10.1109/90.811445
  15. https://www.mdpi.com/2079-9292/12/14/3023
  16. https://dl.acm.org/doi/10.1145/2043164.2018504
  17. https://ieeexplore.ieee.org/document/6900895/
  18. https://ieeexplore.ieee.org/document/1498312/
  19. https://dl.acm.org/doi/abs/10.1109/TC.2016.2560838
  20. https://www.sciencedirect.com/science/article/abs/pii/S1389128609001820
  21. https://faculty.cc.gatech.edu/~dovrolis/Papers/intcoal_pam04.pdf
  22. https://ieeexplore.ieee.org/document/7998242/
  23. https://ieeexplore.ieee.org/document/4411277/
  24. https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics
  25. https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning
  26. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_protocol_cbac_fw/configuration/15-1mt/sec-data-protocol-cbac-fw-15-1mt-book/TCP_Out-of-Order_Packet_Support_for_Cisco_IOS_Firewall_and_Cisco_IOS_IPS.pdf
  27. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-16-7/sec-data-zbf-xe-16-7-book/sec-zone-pol-fw.html
  28. https://datatracker.ietf.org/doc/html/rfc793
  29. https://datatracker.ietf.org/doc/html/rfc9293
  30. https://datatracker.ietf.org/doc/html/rfc2581
  31. https://datatracker.ietf.org/doc/html/rfc1323
  32. https://eprints.gla.ac.uk/3600/1/pack_it.pdf
  33. http://www.csc.lsu.edu/~sjpark/cs7601/3-PacketReorderingFeng.pdf
  34. https://web.ece.ucsb.edu/~hespanha/published/tcp-pr-dec2004.pdf
  35. http://users.csc.calpoly.edu/~bellardo/pubs/imw02-reordering.pdf
  36. https://www.usenix.org/event/imc05/tech/full_papers/luo/luo.pdf
  37. https://www.researchgate.net/publication/224644216_Out_of_order_packets_analysis_on_a_real_network_environment
  38. https://www.researchgate.net/publication/326387056_Measuring_Effect_of_Packet_Reordering_on_Quality_of_Experience_QoE_in_Video_Streaming
  39. https://gafferongames.com/post/udp_vs_tcp/
  40. https://www.networkworld.com/article/762881/data-center-out-of-order-packets-trash-voice-and-video.html
  41. https://mislove.org/publications/QUIC-IMC.pdf
  42. https://webrtchacks.com/how-webrtcs-neteq-jitter-buffer-provides-smooth-audio/
  43. https://www.researchgate.net/publication/335977963_Effect_of_Packet_Loss_and_Reorder_on_Quality_of_Audio_Streaming
  44. https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html
  45. https://www.tcpdump.org/manpages/tcpdump.1.html
  46. https://datatracker.ietf.org/doc/rfc4737/
  47. https://obkio.com/blog/what-is-packet-reordering/
  48. https://iperf.fr/iperf-doc.php
  49. https://doi.org/10.3390/electronics12143023
  50. https://www.ietf.org/archive/id/draft-carpenter-flow-ecmp-02.html
  51. https://docs.aws.amazon.com/prescriptive-guidance/latest/sql-server-ec2-best-practices/tcp-rss.html
  52. https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/load-balancing-mpls-traffic.html
  53. https://www.rfc-editor.org/rfc/rfc1323.html
  54. https://arxiv.org/pdf/2008.03075
  55. https://dl.acm.org/doi/10.1145/3718087
Add your contribution
Related Hubs
User Avatar
No comments yet.