Harry,
The specifications for the SCPS suite of protocols (including transport, network, and security layers) can be found at:
http://www.ccsds.org/documents/pdf/CCSDS-714.0-B-1.pdf
http://www.ccsds.org/documents/pdf/CCSDS-713.0-B-1.pdf
http://www.ccsds.org/documents/pdf/CCSDS-713.5-B-1.pdf
http://www.ccsds.org/documents/pdf/CCSDS-717.0-B-1.pdf
The SCPS Transport protocol (also known as TCP Tranquility) that has received much attention here of late specifies a set of sender-side modifications and some TCP options that can be used to shift TCP's operating domain. That is, any TCP implementation such as TCP Reno (or TCP SACK, ...) has an 'operating regime' where it performs well. Not surprisingly, the operating regime of commonly deployed TCP stacks covers most wired situations, and in a pinch can be stretched across wireless links. TCP Tranquility specifies a set of options that can be used to shift (or extend) TCP's operating domain to perform better in certain stressed conditions, including:
o Long delays (e.g. geosynchronous satellite communications)
o Large data rate asymmetries (e.g. communications with some satellites)
o High bit error rates (e.g. some terrestrial wireless and some space communciations)
o Link outages (e.g. some terrestrial wireless and some space communications)
Additional information about the SCPS protocols, including the results of some flight tests, can be found at http://www.scps.org There's also a point of contact there where you can request a free copy of the TCP Tranquility Reference Implemenation (RI) (full source code). The RI runs on most unix-like operating systems, including solaris, linux, freebsd, ... To get this level of portability, the RI runs in user-space, and applications have to explicitly link in the Tranquility stack (and make appropriate calls). Tranquility versions of FTP and ttcp, useful for network testing, come with the RI.
The RI can also be configured as a Transparent TCP gateway (similar in functionality to some commercial products). In the gateway configuration, Tranquility can implement different congestion control mechanisms on the two sides of the gateway so that it can, for instance, run VJ congestion control with a modest (say 32k) windows on one side (to communicate with terrestrial users) and run with congestion control disabled (i.e. limited only by the rate control setting, discussed below) to communicate with a peer gateway across, say, a satellite hop.
The short answer to your question: what are the differences between TCP Tranquility and, say, TCP NewReno is that Tranquility provides for a number of sender-side modifications to TCP behavior, and a number of negotiated options. The sender-side modifications include:
1 TCP Tranquility provides for the sender-side to use either VJ- or Vegas-style congestion control, or none. Obviously, disabling congestion control is something that should only be done when the Tranquility flow won't interfere with congestion-controlled flows. There are also paced acknowledgement modes useful for very highly asymmetric situations.
2 TCP Tranquility includes a sender-side rate control cap on transmission rate (this can be useful, for example, to prevent the VJ congestion control algorithm from repeatedly driving the bottleneck link into congestion).
In addition, TCP Tranquility specifies a number of TCP options, including:
1 SCPS-Capabilities TCP Option
Used during the SYN exchange to negotiate various TCP Tranquility capabilities such as SNACK, SCPS Loss-Tolerant Header Compression, Partial Reliability Service, ...) If a Tranquility endpoint is communicating with a non-Tranquility endpoint (or another Tranquility stack, for that matter) that does not agree to use SCPS options, either by not including a SCPS capabilities option in the SYN exchange or by including a SCPS-capabilities option that declines all extensions, communications take place using the standard TCP protocol as specified by RFC 793 and its supporting RFCs.
2 Selective Negative Acknowledgements TCP Option
SNACK is a bandwidth-efficient form of NACK useful in moderate to high error rate environments.
3 Record Boundary Marking
TCP Tranquility specifies a method for marking record boundaries in the TCP stream. These record boundaries are indicated at the source and are carried through to the destination.
4 Corruption Experienced TCP Option
TCP Tranquility specifies a way to inform a TCP sender that a link in the path has gone down. This allows the sender to suspend various timers until the link comes back up. This essentially keeps the sender from backing off a lot while waiting for the link to come up.
TCP Tranquility Loss-Tolerant Header Compression
TCP Tranquility specifies a loss-tolerant header compression scheme that does not use delta encoding, as RFC1144 compression does[1]. The loss-tolerant header compression generally doesn't achieve the compression ratios of VJ header compression, but a single corrupted packet does not prevent decompression of later packets at the receiver. If both ends of the connection agree to do Tranqility header compression during the SYN exchange, then the remainder of the connection switches to the TCP Tranquility IP protocol number (105).
TCP Tranquility Partial Reliability Service
During the initial SYN exchange, both endpoints may agree to use partial reliability. This mode of operation allows the sender to 'give up' on retransmitting data after a specified timeout period. The receiver then receives a stream with holes in it. Application-layer support to correctly detect and deal with holes in the received stream is required.
If you have any other questions, I'd be happy to answer,
--keith
[1] VJ Header compression (RFC1144) uses delta-encoding, essentially transmitting the changes to some fields in the TCP/IP headers instead of the whole values. This can be unfriendly to lossy links because there's shared state at the link endpoints that, when a packet is corrupted on the link, becomes inconsistent. This can cause data to fall on the floor until the source retransmits the lost packet. Things like the twice algorithm and the header compression for IPv6 try to get around this problem.
At 09:14 AM 6/19/2002 -0700, Smith JR, Harry E wrote:
>I have been following the thread with interest and enjoyment.
>
>However, as a newcomer to the SCPS, is there a technical summary of the
>differences and extension of the SCPS Suite to the most common stack ( not
>best) Winsock 2.0 ? Or even any commonly used stack?
>
>Thanks
>Harry Smith
>
>----------------------------------------------------------------------------
>Harry Smith
>l
>Systems Engineer Senior Staff
>LM MDS/WR 280/4/26
>
>3200 Zanker Road, MS X-75, San Jose, CA. 95134
>408 473 6491
This archive was generated by hypermail 2b29 : Wed Jun 19 2002 - 15:44:13 EDT