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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/