Browse Prior Art Database

Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions (RFC3708)

IP.com Disclosure Number: IPCOM000022102D
Original Publication Date: 2004-Feb-01
Included in the Prior Art Database: 2004-Feb-25
Document File: 10 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Blanton: AUTHOR [+2]

Abstract

TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 17% of the total text.

Network Working Group E. Blanton

Request for Comments: 3708 Purdue University

Category: Experimental M. Allman

ICIR

February 2004

Using TCP Duplicate Selective Acknowledgement (DSACKs) and

Stream Control Transmission Protocol (SCTP) Duplicate

Transmission Sequence Numbers (TSNs) to Detect Spurious

Retransmissions

Status of this Memo

This memo defines an Experimental Protocol for the Internet

community. It does not specify an Internet standard of any kind.

Discussion and suggestions for improvement are requested.

Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

TCP and Stream Control Transmission Protocol (SCTP) provide

notification of duplicate segment receipt through Duplicate Selective

Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number

(TSN) notification, respectively. This document presents

conservative methods of using this information to identify

unnecessary retransmissions for various applications.

1. Introduction

TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate

segment receipt through duplicate selective acknowledgment (DSACK)

[RFC2883] and Duplicate TSN notifications, respectively. Using this

information, a TCP or SCTP sender can generally determine when a

retransmission was sent in error. This document presents two methods

for using duplicate notifications. The first method is simple and

can be used for accounting applications. The second method is a

conservative algorithm to disambiguate unnecessary retransmissions

from loss events for the purpose of undoing unnecessary congestion

control changes.

Blanton & Allman Experimental [Page 1]

RFC 3708 TCP DSACKs and SCTP Duplicate TSNs February 2004

This document is intended to outline reasonable and safe algorithms

for detecting spurious retransmissions and discuss some of the

considerations involved. It is not intended to describe the only

possible method for achieving the goal, although the guidelines in

this document should be taken into consideration when designing

alternate algorithms. Additionally, this document does not outline

what a TCP or SCTP sender may do after a spurious retransmission is

detected. A number of proposals have been developed (e.g.,

[RFC3522], [SK03], [BDA03]), but it is not yet clear which of these

proposals are appropriate. In addition, they all rely on detecting

spurious retransmits and so can share the algorithm specified in this

document.

Finally, we note that to simplify the text much of the following

discussion is in terms of TCP DSACKs, while applying to both TCP and

SCTP.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in RFC 2119 [RFC2119].

2. Counting Duplicate Notifications

For certain applications a straight count of duplicate notifications

will suffice. For instance, if a stack simply wants to...