Keith,
Thanks for the summary. It may be useful to put this summary (the stuff
below) on the SCPS site as it is probably a question that comes up
often. Reading this summary is much easier that examining the documents.
Will
>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.
>
=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road MS 54-5
Cleveland, Ohio 44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger ID: ivancic
http://roland.grc.nasa.gov/~ivancic
This archive was generated by hypermail 2b29 : Thu Jun 20 2002 - 07:59:49 EDT