Skip to main content

Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP
draft-natarajan-tsvwg-sctp-nrsack-08

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Nasif Ekiz , Professor Paul D. Amer , Preethi Natarajan , Randall R. Stewart , Jana Iyengar
Last updated 2011-08-15
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

Stream Control Transmission Protocol (SCTP) [RFC4960] specifies Selective Acknowledgements (SACKs) to allow an SCTP data receiver to acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK information is advisory -- though SACKs notify a data sender about the reception of specific out-of-order data, the SCTP data receiver is permitted to later discard the data, a.k.a reneging. Since delivery of a SACKed out-of-order DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept in the data sender's retransmission queue until this DATA chunk is cumulatively acked. By definition, data that has been delivered to the application is non-renegable by the SCTP data receiver. (Recall that, in SCTP, out- of-order data can sometimes be delivered.) Also, SCTP implementations can be configured such that the SCTP data receiver is not allowed to, and therefore, never reneges on out-of-order data. With SCTP's current SACK mechanism, non-renegable out-of-order data is selectively acked, and is (wrongly) deemed renegable by the SCTP data sender. This document specifies an extension to SCTP's acknowledgment mechanism called Non-Renegable Selective Acknowledgements (NR-SACKs.) NR-SACKs enable a data receiver to explicitly inform the data sender of non-renegable out-of-order data. As opposed to renegable data, a data sender can consider non-renegable data as never requiring retransmission, and therefore can remove non-renegable data from the retransmission queue.

Authors

Nasif Ekiz
Professor Paul D. Amer
Preethi Natarajan
Randall R. Stewart
Jana Iyengar

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)