The article "The Size of Packets" explores the distribution of IP packet sizes on the internet, emphasizing the enduring prevalence of small packets despite increasing bandwidth. It analyzes data from various sources, highlighting that the median packet size remains stubbornly around 400-500 bytes, even on high-speed links. This challenges the assumption that larger packets dominate modern networks and underscores the importance of optimizing network infrastructure for small packet efficiency. The piece also delves into the historical context of packet sizes, touching on Ethernet's influence and the continued relevance of TCP/IP headers, which contribute significantly to the overall size, especially for smaller payloads.
Without TCP or UDP, internet communication as we know it would cease to function. Applications wouldn't have standardized ways to send and receive data over IP. We'd lose reliability (guaranteed delivery, in-order packets) provided by TCP, and the speed and simplicity offered by UDP. Developers would have to implement custom protocols for each application, leading to immense complexity, incompatibility, and a much less efficient and robust internet. Essentially, we'd regress to a pre-internet state for networked applications, with ad-hoc solutions and significantly reduced interoperability.
Hacker News users discussed alternatives to TCP/UDP and the implications of not using them. Some highlighted the potential of QUIC and HTTP/3 as successors, emphasizing their improved performance and reliability features. Others explored lower-level protocols like SCTP as a possible replacement, noting its multi-streaming capabilities and potential for specific applications. A few commenters pointed out that TCP/UDP abstraction is already somewhat eroded in certain contexts like RDMA, where applications can interact more directly with the network hardware. The practicality of replacing such fundamental protocols was questioned, with some suggesting it would be a massive undertaking with limited benefits for most use cases. The discussion also touched upon the roles of the network layer and the possibility of protocols built directly on IP, acknowledging potential issues with fragmentation and reliability.
Summary of Comments ( 28 )
https://news.ycombinator.com/item?id=43723884
HN users generally agree with the article's premise that smaller packets are better for latency. Several commenters note the importance of considering protocol overhead when discussing packet size, particularly in the context of VoIP and gaming where latency is critical. Some point out the trade-off between smaller packets (lower latency) and larger packets (higher throughput), suggesting that the "optimal" packet size depends on the specific application and network conditions. One commenter questions the article's dismissal of jumbo frames, arguing they can be beneficial in certain scenarios like data centers. Others offer additional resources and technical explanations regarding packet fragmentation and reassembly. A few commenters discuss the historical context of packet size, referencing older protocols and network limitations.
The Hacker News post "The Size of Packets" (https://news.ycombinator.com/item?id=43723884), which links to an article discussing internet packet sizes, has a moderate number of comments that delve into various aspects of networking and performance.
Several commenters discuss the historical context of packet sizes and the evolution of network technology. One commenter highlights the limitations of early Ethernet, which had a maximum transmission unit (MTU) of 1500 bytes, and how this influenced the common packet size seen today. Another points out that the introduction of jumbo frames, which allow for larger packets, aimed to improve efficiency but faced adoption challenges due to fragmentation issues and inconsistent support across networks. The complexities of balancing larger packet sizes for efficiency against the potential for increased latency and retransmissions due to errors are explored in several comments.
The topic of network overhead is also raised, with commenters discussing the proportion of a packet dedicated to headers versus actual data. The impact of different protocols, such as IPv4 and IPv6, on packet overhead is mentioned. One commenter provides specific calculations showing the overhead percentages for various scenarios, highlighting the significance of this overhead, especially with smaller packets.
Performance implications are a central theme. Some comments discuss the relationship between packet size, latency, and throughput, acknowledging that larger packets can reduce overhead and improve throughput but also increase latency in certain situations. The practical challenges of tuning network parameters to optimize for specific applications are also acknowledged.
Security considerations are briefly touched upon. One commenter points out that smaller packets can be beneficial for security in some contexts by reducing the impact of a single lost or corrupted packet.
Finally, a few comments offer anecdotal experiences and observations related to network performance and packet sizes in different environments. One commenter shares an experience with satellite internet where smaller packets were found to be more reliable, illustrating the real-world impact of these technical details.
Overall, the comments provide a range of perspectives on the nuances of packet sizes and their implications for network performance and efficiency. They highlight the ongoing balancing act between maximizing throughput while minimizing latency and ensuring reliability in diverse network environments. The discussion is grounded in technical details but also incorporates practical experience and historical context, offering a valuable supplement to the linked article.