Re: Satellites running IP

[William Ivancic <[e-mail]>]

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 [phone]
Fax [phone]
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic