BCP 69

RFC 3449

TCP Performance Implications of Network Path Asymmetry, December 2002

File formats:
icon for text file icon for PDF icon for HTML
Status:
BEST CURRENT PRACTICE
Authors:
H. Balakrishnan
V. Padmanabhan
G. Fairhurst
M. Sooriyabandara
Stream:
IETF
Source:
pilc (tsv)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC3449

Discuss this RFC: Send questions or comments to the mailing list iesg@ietf.org

Other actions: Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 3449


Abstract

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.


For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.




Advanced Search