Browse Prior Art Database

An Extension to the Selective Acknowledgement (SACK) Option for TCP (RFC2883)

IP.com Disclosure Number: IPCOM000003483D
Original Publication Date: 2000-Jul-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 17 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Floyd: AUTHOR [+3]

Related Documents

10.17487/RFC2883: DOI

Abstract

This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 10% of the total text.

Network Working Group S. Floyd Request for Comments: 2883 ACIRI Category: Standards Track J. Mahdavi Novell M. Mathis Pittsburgh Supercomputing Center M. Podolsky UC Berkeley July 2000

An Extension to the Selective Acknowledgement (SACK) Option for TCP

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

This note defines an extension of the Selective Acknowledgement (SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP’s cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts.

1. Conventions and Acronyms

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [B97].

Floyd, et al. Standards Track [Page 1]

RFC 2883 SACK Extension July 2000

2. Introduction

The Selective Acknowledgement (SACK) option defined in RFC 2018 is used by the TCP data receiver to acknowledge non-contiguous blocks of data not covered by the Cumulative Acknowledgement field. However, RFC 2018 does not specify the use of the SACK option when duplicate segments are received. This note specifies the use of the SACK option when acknowledging the receipt of a duplicate packet [F99]. We use the term D-SACK (for duplicate-SACK) to refer to a SACK block that reports a duplicate segment.

This document does not make any changes to TCP’s use of the cumulative acknowledgement field, or to the TCP receiver’s decision of *when* to send an acknowledgement packet. This document only concerns the contents of the SACK option when an acknowledgement is sent.

This extension is compatible with current implementations of the SACK option in TCP. That is, if one of the TCP end-nodes does not implement this D-SACK extension and the other TCP end-node does, we believe that this use of the D-SACK extension by one of the end nodes will not introduce problems.

The use of...

Processing...
Loading...