Some thoughts on the packet network architecture
ACM SIGCOMM Computer Communication Review
SIGCOMM '88 Symposium proceedings on Communications architectures and protocols
The experimental literature of the internet: an annotated bibliography
ACM SIGCOMM Computer Communication Review
Bibliography on network management
ACM SIGCOMM Computer Communication Review
Analysis and simulation of a fair queueing algorithm
SIGCOMM '89 Symposium proceedings on Communications architectures & protocols
A binary feedback scheme for congestion avoidance in computer networks
ACM Transactions on Computer Systems (TOCS)
How slow is one gigabit per second?
ACM SIGCOMM Computer Communication Review
Virtual clock: a new traffic control algorithm for packet switching networks
SIGCOMM '90 Proceedings of the ACM symposium on Communications architectures & protocols
VirtualClock: a new traffic control algorithm for packet-switched networks
ACM Transactions on Computer Systems (TOCS)
Loss-load curves: support for rate-based congestion control in high-speed datagram networks
SIGCOMM '91 Proceedings of the conference on Communications architecture & protocols
Observations on the dynamics of a congestion control algorithm: the effects of two-way traffic
SIGCOMM '91 Proceedings of the conference on Communications architecture & protocols
Improving round-trip time estimates in reliable transport protocols
ACM Transactions on Computer Systems (TOCS)
The Q-bit scheme: congestion avoidance using rate-adaptation
ACM SIGCOMM Computer Communication Review
High performance TCP in ANSNET
ACM SIGCOMM Computer Communication Review
A simulation study of the mechanisms to enhance TCP protocol in wide area computer networks
SAC '96 Proceedings of the 1996 ACM symposium on Applied Computing
(Comments) on "Congestion Control in IP/TCP Internetworks"
ACM SIGCOMM Computer Communication Review
Comments on "congestion control in TCP/IP internetworks"
ACM SIGCOMM Computer Communication Review
Computer Networks: The International Journal of Computer and Telecommunications Networking
Measurement and analysis of LDAP performance
IEEE/ACM Transactions on Networking (TON)
Removing exponential backoff from TCP
ACM SIGCOMM Computer Communication Review
Application-level QoS: improving video conferencing quality through sending the best packet next
International Journal of Internet Protocol Technology
Comments on "Comments on 'Congestion Control in TCP/IP Internetworks'" or the holy wars begin again
ACM SIGCOMM Computer Communication Review
Transport-independent fairness
Computer Networks: The International Journal of Computer and Telecommunications Networking
A nonlinear control theoretic analysis to TCP-RED system
Computer Networks: The International Journal of Computer and Telecommunications Networking
An efficient implementation of GPU virtualization in high performance clusters
Euro-Par'09 Proceedings of the 2009 international conference on Parallel processing
An Architecture for Network Congestion Control and Charging of Non-cooperative Traffic
Journal of Network and Systems Management
netShip: a networked virtual platform for large-scale heterogeneous distributed embedded systems
Proceedings of the 50th Annual Design Automation Conference
Hi-index | 0.00 |
Congestion control is a recognized problem in complex networks. We have discovered that the Department of Defense's Internet Protocol (IP), a pure datagram protocol, and Transmission Control Protocol (TCP), a transport layer protocol, when used together, are subject to unusual congestion problems caused by interactions between the transport and datagram layers. In particular, IP gateways are vulnerable to a phenomenon we call congestion collapse, especially when such gateways connect networks of widely different bandwidth. We have developed solutions that prevent congestion collapse. These problems are not generally recognized because these protocols are used most often on networks built on top of ARPANET IMP technology. ARPANET IMP based networks traditionally have uniform bandwidth, identical switching nodes, and are sized with substantial excess capacity. This excess capacity, and the ability of the IMP system to throttle the transmissions of hosts has for most IP/TCP hosts and networks, been adequate to handle congestion. With the recent split of the ARPANET into two interconnected networks and the growth of other networks with differing properties connected to the ARPANET, however, reliance on the benign properties of the IMP system is no longer enough to allow hosts to communicate rapidly and reliably. Improved handling of congestion is now mandatory for successful network operation under load. Ford Aerospace and Communications Corporation, and its parent company, Ford Motor Company, operate the only private IP/TCP long-haul network in existence today. This network connects six facilities (one in Michigan, two in California, one in Colorado, one in Texas, and one in England) some with extensive local networks. This net is cross-tied to the ARPANET but uses its own long-haul circuits; traffic between Ford facilities flows over private leased circuits, including a leased transatlantic satellite connection. All switching nodes are pure IP datagram switches with no node-to-node flow control, and all hosts run software either written or heavily modified by Ford or Ford Aerospace. Bandwidth of links in this network varies widely, from 1200 to 10,000,000 bits per second. In general, we have not been able to afford the luxury of excess long-haul bandwidth that the ARPANET possesses, and our long-haul links are heavily loaded during peak periods. Transit times of several seconds are thus common in our network. Because of our pure datagram orientation, heavy loading, and wide variation in bandwidth, we have had to solve problems that the ARPANET/MILNET community is just beginning to recognize. Our network is sensitive to suboptimal behavior by host TCP implementations, both on and off our own net. We have devoted considerable effort to examining TCP behavior under various conditions, and have solved some widely prevalent problems with TCP. We present here two problems and their solutions. Many TCP implementations have these problems; if throughput is worse through an ARPANET/MILNET gateway for a given TCP implementation than throughput across a single net, there is a high probability that the TCP implementation has one or both of these problems.