>Status: R
>From: "Falk, Aaron" <[email protected]>
>To: "'[email protected]'" <[email protected]>
>Cc: "Mark A. Allman (E-mail)" <[email protected]>
>Subject: Working group last call for res-issues (-12)
>Date: Thu, 21 Oct 1999 16:43:51 -0400
>MIME-Version: 1.0
>Sender: [email protected]
>Precedence: bulk
>
>Since there have been some significant modifications to -res-issues- it will
>go through another working group last call. Please send substantive comments
>to the list ASAP. The text file can be retrieved via
>http://www.ietf.org/internet-drafts/draft-ietf-tcpsat-res-issues-12.txt.
>
>Thanks,
>
>--aaron
Mark: This is a slightly edited version of the material I submitted
to you at the end of March, updated to include the IANA assigned TCP
option numbers for the SCPS extensions. I wonder if since the
res-issues document is going to last call again if there is an
opportunity to include it at this time?
======================
The Space Communications Protocol Standards (SCPS) protocols are the
result of a project whose goal is to extend internet protocols into
stressed environments, including space. The full SCPS stack includes
bit-efficient network, security, transport, and application-layer
protocols; this section focuses on the SCPS transport layer protocol,
SCPS-TP, designed to operate in environments characterized by one or
more of the following:
* Highly asymmetric bandwidth
* Large delays
* Link outages
* A high degree of corruption-related loss
Except when using its optional compressed header format, SCPS-TP is a
conformant TCP implementation with the addition of sender-side
behaviors such as rate control, and a number of options negotiated
during the SYN exchange. Thus SCPS should be thought of as a
collection of TCP options and extensions, not as a separate protocol.
Some of the SCPS options (Selective Negative Acknowledgments, Record
Boundaries, Network-Layer Timestamps, and SCPS Header Compression)
are negotiated during the SYN exchange, while others are set at
SCPS-capable endpoints via some other method (for our reference
software, this is an enhanced socket interface). To reduce the
burden on assigned TCP option numbers, an endpoint�s willingness to
use SNACK, Record Boundaries, Network-Layer Timestamps, and SCPS
Header compression are all negotiated under a single TCP option in
the SYN segments (TCP option #20: SCPS Capabilities).
If none of the enhanced options are used or if the peer does not
agree to use the SCPS extensions, a SCPS-TP capable endpoint will
communicate using the standard TCP protocol as specified by RFC 793
and its supporting RFCs.
The following describes the various TCP options and extensions with
which we have experimented:
Congestion Control Algorithms Including Pure Rate Control
---------------------------------------------------------
The enhanced socket interface of the SCPS-TP reference implementation
(running outside the kernel) allows applications to specify the
congestion control algorithm they want to use. Current congestion
control algorithms include NewReno and Vegas (each possibly coupled
with rate control), and pure token-bucket rate control. The pure
rate control option is appropriate, for example, if the session is
running over a network layer that guarantees fixed bandwidth and no
contention. We are currently experimenting with an interface between
the rate control mechanism and an enhanced RSVP implementation that
will allow the sender to use pure rate control to over an
RSVP-capable network.
Explicit Corruption Notification -- TCP Option #23 and a custom ICMP message
------------------------------------------------------------------------------
The Corruption Experienced Option provides a means for a TCP
connection to react to data loss caused by corruption differently
than to loss caused by congestion. Currently, TCP assumes that all
loss is a result of congestion. When losses are due to corruption,
TCP's congestion response is inappropriate, and has a negative effect
on throughput. Use of the Explicit Corruption Notification option is
only appropriate in networks where congestion is explicitly signaled.
In the absence of an explicit corruption signal, loss is assumed to
be due to congestion, and congestion recovery mechanisms are invoked.
There remains a further issue, which is the coincidence of corruption
in one portion of the network and severe congestion in another. The
case in which (all) congestion signals fail either due to congestion
collapse or corruption of the congestion signals is under study.
Corruption signaling is accomplished at both the network control
(ICMP) layer and at the transport layer. A router declares one of
its inbound interfaces to be corrupted in response to a signal from
the link layer entity, by polling inbound error counts, or by other
means. The router uses a least-recently-used queue approach to
inform recent near-side users of that link that it is corrupted, and
of the source-destination address pairs traversing the corrupted
link. This information is carried to the near-side users via a
network layer control message (e.g. a new ICMP message type). The
receiving host responds to this message by sending the "corruption
experienced" option (TCP option 23) to its peer.
When a sending TCP receives evidence that packets need to be
retransmitted (via duplicate acknowledgments, a SNACK, or a
retransmission timeout) it checks to see if the path is marked as
corrupted. If the path is not marked as corrupted, the sending TCP
updates its transmission policy according to the rules of the
congestion control algorithm in use. If the path is marked as
corrupted, the sending TCP may choose to not modify its cwnd and
ssthresh variables (i.e. it may choose not to cut its transmission
rate). Additionally, when there is evidence that data loss is due to
corruption rather than congestion, the sending TCP may choose not to
use the "exponential backoff" algorithm to increase the time between
successive retransmissions. Note that any indication of congestion,
explicitly signaled or implicit via other information overrides the
corruption experienced option and invokes the congestion response.
The rationale for using a combination of network layer signaling and
a TCP option is as follows. We need to inform both endpoints of the
connection that the link is corrupted, but it is a router on the
receiving side of the link that has this information. If the link is
corrupted in both directions and the data and acknowledgment streams
both traverse the link, fine; the routers on either side of the
corrupted link will inform their respective endpoints via
network-layer signaling. Note that in this case, neither router has
much hope of sending an ICMP-type message across the corrupted link
to inform the endpoint on the other side of the corruption. If only
one of the [data, acknowledgment] streams traverses the corrupted
link, then the most reliable means of notifying the endpoint on the
sending side of that link is by having the endpoint on the receiving
side of the link set an option in the TCP header of an outbound
packet, and allowing the packet to traverse the non-corrupted path
back to the sending side.
Link Outage Notification
------------------------
It may be the case that a link becomes temporarily unavailable, due
to a satellite temporarily passing out of view of a groundstation, a
handover in a mobile network, or other short-term interruption. Our
TCP implementation includes the ability to react appropriately to
these types of interruption, provided that some other entity (say a
groundstation that loses carrier lock on a signal, e.g.) is able to
notify the endpoint via a "Link Outage" ICMP-type signal. On
receiving such a signal, the SCPS-TP-capable endpoint enters a
persist state, periodically sending small packets to probe the link.
In this case the endpoint does NOT periodically time out, retransmit,
and back-off the retransmission timer; instead it suspends its
regular timers and only sends the small probe packets. If a probe
packet is acknowledged, or if a "Link Restored" message is received,
the endpoint resumes its timers and continues transmitting.
Selective Negative Acknowledgments -- TCP Option #21
------------------------------------------------------
One of the TCP options we have implemented gives a session the
ability to use selective negative acknowledgments, or SNACKs. The
receiving endpoint may send a SNACK Option on an ACK segment whenever
an out-of-sequence queue forms or a new hole in the out-of-sequence
queue forms, provided that the sender advertised its ability to
receive by setting the appropriate bits in the SCPS capabilities
option during the SYN exchange. Upon receipt of a SNACK Option, the
data-sender shall retransmit all segments necessary to fill the
signaled holes. We are investigating embargo strategies where a
receiver does NOT re-SNACK missing segments for at least a round-trip
time, to give the sender a chance to respond before additional SNACKs
are sent.
Best Effort Transport Service (BETS)
------------------------------------
The Best Effort Transport Service (BETS) Option provides a means for
applications to allow the transport layer to declare a particular
segment undeliverable after some period of time and to move on with
transmission. APIs at the sender and receiver allow the sender to
query for which bytes were declared received without acknowledgment,
and to allow the receiver to query for which bytes were not received.
For this option to make sense, applications need to be able to deal
with partial transmissions, as might be the case with hierachically
encoded images.
SCPS Header Compression
-----------------------
SCPS header compression is negotiated during the SYN exchange at the
beginning of a connection, and differs from the TCP/IP header
compression scheme described in RFC 1144 in several ways. First,
SCPS-TP header compression is end-to-end instead of hop-by-hop as in
RFC 1144. Second, SCPS header compression does NOT use the
delta-encoding of RFC 1144. Instead, connections are identified by a
single 1-octet connectionID, and contain the full values of various
TCP header fields (e.g. ack number, urgent pointer, etc.) Specific
fields are included only if needed, and the presence/absence of each
field is indicated in a compressed "mini-header" that is essentially
a two octet bit field following the connectionID. Using this method,
SCPS receivers can continue to process headers after a loss, which
greatly increases the utility of fast retransmission.
Reduced Ack Frequency
---------------------
For highly asymmetric channels where the forward, or data channel has
high bandwidth and the return, or ACK channel has very low bandwidth,
TCP's standard mechanism of acknowledging at least every other packet
may overload the ACK channel. SCPS-capable endpoints can be
configured to limit the bandwidth used by the acknowledgment stream.
For highly asymmetric channels, this would lead to very bursty
behavior if not for SCPS-TP's rate control, which can be configured
to smooth the data stream somewhat.
Record Boundaries -- TCP Option #22
-------------------------------------
The Record Boundary Option provides a way for applications to send
and receive record boundary indicators that are preserved across
transmission (and possible retransmission) by SCPS-TP. When using
record boundaries, the sending application indicates, via an
Application Programming Interface (API) specific method to the
transport layer, that the final octet of data in a particular request
represents the end of a record. The final octet of the request is
then logically marked by the transport layer with the end-of-record
mark, and this logical marking is preserved across transmission and
possible retransmission of the marked byte. A read operation at the
receiver associates the end of record marker with the marked octet.
Note that record boundaries are treated the same as regular data.
Specifically, if an application requests both record boundaries and
best effort service (BETS), bytes marked as record boundaries may be
lost. It is the application developer's responsibility to ensure
that the application is robust against the possibility of such losses.
Network-Layer Timestamps
------------------------
In some cases the network layer is able to provide a timestamp
mechanism that are more efficient than including TCP-like timestamps
in the SCPS-TP header. By agreeing to use network-layer timestamps
in these cases, SCPS-TP connections can save bandwidth. This feature
was included for dealing with extremely bandwidth constrained
environments.
References
----------
J. Postel. Transmission Control Protocol. IAB STD 7. RFC 793,
September 1, 1981.
Space Communications Protocol Specification (SCPS)-Transport Protocol
(SCPS-TP). Draft Recommendation for Space Data System Standards,
CCSDS 714.0-R-3. Washington, D.C.: CCSDS, September 1997.
Robert Durst, Gregory Miller, and Eric Travis, TCP Extensions for
Space Communications, ACM MobiComm, November 1996.
R. Fox, "TCP Big Window and Nak Options," RFC 1106, June 1989.
M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective
Acknowledgment Options," RFC 2018, October 1996
The SCPS web page: http://www.scps.org
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:57 EST