--- 1/draft-ietf-taps-transports-13.txt 2016-12-06 08:13:27.560519395 -0800 +++ 2/draft-ietf-taps-transports-14.txt 2016-12-06 08:13:27.660522035 -0800 @@ -1,21 +1,21 @@ Network Working Group G. Fairhurst, Ed. Internet-Draft University of Aberdeen Intended status: Informational B. Trammell, Ed. -Expires: June 8, 2017 M. Kuehlewind, Ed. +Expires: June 9, 2017 M. Kuehlewind, Ed. ETH Zurich - December 05, 2016 + December 06, 2016 Services provided by IETF transport protocols and congestion control mechanisms - draft-ietf-taps-transports-13 + draft-ietf-taps-transports-14 Abstract This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 8, 2017. + This Internet-Draft will expire on June 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -324,21 +324,22 @@ transport service not to delay data. By default, TCP segment partitioning uses Nagle's algorithm [RFC0896] to buffer data at the sender into large segments, potentially incurring sender-side buffering delay; this algorithm can be disabled by the sender to transmit more immediately, e.g., to reduce latency for interactive sessions. TCP provides an "urgent data" function for limited out-of-order delivery of the data. This function is deprecated [RFC6093]. - A RESET control message may be used to close a TCP session [RFC0793]. + A TCP Reset (RST) control message may be used to force a TCP endpoint + to close a session [RFC0793], aborting the connection. A mandatory checksum provides a basic integrity check against misdelivery and data corruption over the entire packet. Applications that require end to end integrity of data are recommended to include a stronger integrity check of their payload data. The TCP checksum [RFC1071] [RFC2460] does not support partial payload protection (as in DCCP/UDP-Lite). TCP supports only unicast connections. @@ -743,20 +744,23 @@ SCTP, the application can use almost all services provided by SCTP. [I-D.ietf-tsvwg-natsupp] defines methods for endpoints and middleboxes to provide NAT traversal for SCTP over IPv4. For legacy NAT traversal, [RFC6951] defines the UDP encapsulation of SCTP- packets. Alternatively, SCTP packets can be encapsulated in DTLS packets as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. The latter encapsulation is used within the WebRTC [I-D.ietf-rtcweb-transports] context. + An SCTP ABORT chunk may be used to force a SCTP endpoint to close a + session [RFC4960], aborting the connection. + SCTP has a well-defined API, described in the next subsection. 3.5.2. Interface Description [RFC4960] defines an abstract API for the base protocol. This API describes the following functions callable by the upper layer of SCTP: Initialize, Associate, Send, Receive, Receive Unsent Message, Receive Unacknowledged Message, Shutdown, Abort, SetPrimary, Status, Change Heartbeat, Request Heartbeat, Get SRTT Report, Set Failure Threshold, Set Protocol Parameters, and Destroy. The following @@ -966,20 +969,23 @@ unacknowledged segments, to measure RTT, etc. The protocol may support unordered delivery of data, and does not itself provide retransmission. DCCP supports reduced checksum coverage, a partial payload protection mechanism similar to UDP-Lite. There is also a Data Checksum option, which when enabled, contains a strong CRC, to enable endpoints to detect application data corruption. Receiver flow control is supported, which limits the amount of unacknowledged data that can be outstanding at a given time. + A DCCP Reset packet may be used to force a DCCP endpoint to close a + session [RFC4340], aborting the connection. + DCCP supports negotiation of the congestion control profile between endpoints, to provide plug-and-play congestion control mechanisms. Examples of specified profiles include "TCP-like" [RFC4341], "TCP- friendly" [RFC4342], and "TCP-friendly for small packets" [RFC5622]. Additional mechanisms are recorded in an IANA registry. A lightweight UDP-based encapsulation (DCCP-UDP) has been defined [RFC6773] that permits DCCP to be used over paths where DCCP is not natively supported. Support for DCCP in NAPT/NATs is defined in [RFC4340] and [RFC5595]. Upper layer protocols specified on top of