Subject: SCPS TCP extensions for res-issues draft

From: [email-masked] (Keith Scott)
Date: Sun, 24 Oct 1999 10:52:21 -0400

>Status: R
>From: "Falk, Aaron" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Cc: "Mark A. Allman (E-mail)" <[email-masked]>
>Subject: Working group last call for res-issues (-12)
>Date: Thu, 21 Oct 1999 16:43:51 -0400
>MIME-Version: 1.0
>Sender: [email-masked]
>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

---

From: Mark Allman <[email-masked]>
Date: Mon, 25 Oct 1999 10:35:29 -0400

> 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?

I don't think so.  Like I have said in previous notes, I stopped
accepting new material a while back.  This whole last call period
has been fixing things in the draft.  I am *hoping* that I have
editted the draft for the last time and any tweaks that need to
happen now are small enough that the RFC Editor can handle them.

(Just to clarify the above...  I am still open to substantive
comments about the material currently in the draft.  If something is
wrong in there I would like to know about it and am willing to rev
the document to get it right.  But, I *hope* I have fixed everything
at this point.)

Thanks,
allman