The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.

/pdf/the-newreno-modification-to-tcp-s-fast-recovery-algorithm-3yrikte01t.pdf

The NewReno Modification to TCP's Fast Recovery Algorithm

Concurrent multipath transfer (CMT) uses the Stream Control Transmission Protocol's (SCTP) multihoming feature to distribute data across multiple end-to-end paths in a multihomed SCTP association. We identify three negative side-effects of reordering introduced by CMT that must be managed before efficient parallel transfer can be achieved: (1) unnecessary fast retransmissions by a sender; (2) overly conservative congestion window (cwnd) growth at a sender; and (3) increased ack traffic due to fewer delayed acks by a receiver. We propose three algorithms which augment and/or modify current SCTP to counter these side-effects. Presented with several choices as to where a sender should direct retransmissions of lost data, we propose five retransmission policies for CMT. We demonstrate spurious retransmissions in CMT with all five policies and propose changes to CMT to allow the different policies. CMT is evaluated against AppStripe, which is an idealized application that stripes data over multiple paths using multiple SCTP associations. The different CMT retransmission policies are then evaluated with varied constrained receive buffer sizes. In this foundation work, we operate under the strong assumption that the bottleneck queues on the end-to-end paths used in CMT are independent.

/pdf/concurrent-multipath-transfer-using-sctp-multihoming-over-95q6lp12jq.pdf

Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths

Fast-growing Internet applications like streaming media and telephony prefer timeliness to reliability, making TCP a poor fit. Unfortunately, UDP, the natural alternative, lacks congestion control. High-bandwidth UDP applications must implement congestion control themselves-a difficult task-or risk rendering congested networks unusable. We set out to ease the safe deployment of these applications by designing a congestion-controlled unreliable transport protocol. The outcome, the Datagram Congestion Control Protocol or DCCP, adds to a UDP-like foundation the minimum mechanisms necessary to support congestion control. We thought those mechanisms would resemble TCP's, but without reliability and, especially, cumulative acknowledgements, we had to reconsider almost every aspect of TCP's design. The resulting protocol sheds light on how congestion control interacts with unreliable transport, how modern network constraints impact protocol design, and how TCP's reliable bytestream semantics intertwine with its other mechanisms, including congestion control.

/pdf/designing-dccp-congestion-control-without-reliability-3cc5xfv8v7.pdf

Designing DCCP: congestion control without reliability

Foreword. Preface. List of Tables. List of Figures. 1. Introduction . 1.1 Who should read this book? 1.2 Contents. 1.3 Structure. 2. Congestion control principles. 2.1 What is congestion? 2.2 Congestion collapse. 2.3 Controlling congestion: design considerations. 2.4 Implicit feedback. 2.5 Source behaviour with binary feedback. 2.6 Stability. 2.7 Rate-based versus window-based control. 2.8 RTT estimation. 2.9 Traffic phase effects. 2.10 Queue management. 2.11 Scalability. 2.12 Explicit feedback. 2.13 Special environments. 2.14 Congestion control and OSI layers. 2.15 Multicast congestion control. 2.16 Incentive issues. 2.17 Fairness. 2.18 Conclusion. 3. Present technology. 3.1 Introducing TCP. 3.2 TCP window management. 3.3 TCP RTO calculation. 3.4 TCP congestion control and reliability. 3.5 Concluding remarks about TCP. 3.6 The Stream Control Transmission Protocol (SCTP). 3.7 Random Early Detection (RED). 3.8 The ATM'Available Bit Rate' service. 4. Experimental enhancements. 4.1 Ensuring appropriate TCP behaviour. 4.2 Maintaining congestion state. 4.3 Transparent TCP improvements. 4.4 Enhancing active queue management. 4.5 Congestion control for multimedia applications. 4.6 Better-than-TCP congestion control. 4.7 Congestion control in special environments. 5. Internet traffic management - the ISP perspective. 5.1 The nature of Internet traffic. 5.2 Traffic engineering. 5.3 Quality of Service (QoS). 5.4 Putting it all together. 6. The future of Internet congestion control. 6.1 Small deltas or big ideas? 6.2 Incentive issues. 6.3 Tailor-made congestion control. Appendix A: Teaching congestion control with tools. A.1 CAVT. A.1.1 Writing script. A.1.2 Teaching with CAVT. A.1.3 Internals. A.2 ns. A.2.1 Using ns for teaching: the problem. A.2.2 Using ns for teaching: the solution. A.2.3 NSBM. A.2.4 Example exercises. Appendix B: Related IETF work. B.1 Overview. B.2 Working groups. B.3 Finding relevant documents. Appendix C: List of abbreviations. Bibliography. Index.

https://leseprobe.buch.de/images-adb/8b/9f/8b9f6edb-563b-46aa-a7a1-014b5cc86f60.pdf

Network Congestion Control: Managing Internet Traffic

This document contains the profile for Congestion Control Identifier 2
(CCID 2), TCP-like Congestion Control, in the Datagram Congestion
Control Protocol (DCCP). CCID 2 should be used by senders who would
like to take advantage of the available bandwidth in an environment
with rapidly changing conditions, and who are able to adapt to the
abrupt changes in the congestion window typical of TCP's Additive
Increase Multiplicative Decrease (AIMD) congestion control.
[STANDARDS-TRACK]

/pdf/profile-for-datagram-congestion-control-protocol-dccp-56agjo6rkw.pdf

Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.

/pdf/a-conservative-selective-acknowledgment-sack-based-loss-1566cuyekx.pdf

L. Wang

Papers

A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP