At 11:51 AM 6/14/2002 -0400, William Ivancic wrote:
>At 01:52 PM 6/14/02 +0100, Lloyd Wood wrote:
>>On Thu, 13 Jun 2002, David Carek wrote:
>>
>>> I'm looking for existing satellites that use IP or other Internet
>>> protocols on board or in their air to ground communications. .....
>>
>>
>>Really, isn't this what NASA et al. have been developing SCPS for?
>>
>>L.
>
>Does anyone know of someone "flying" an onboard SCPS stack?
>
>Does anyone know of any commercial applications that call the SCPS-TP options. SCPS-FP is the only application one I know of.
Xiphos (http://www.xiphos.com) is developing an in-kernel SCPS-TP implementation. Presumably they'll have some sysadmin-settable 'default' settings (I'd set SNACK and Vegas both on by default, e.g.) and then individual applications can use setsockopt calls if they want to fine-tune things. The point is, using xiphos' stack, all applications will have access to the SCPS enhancements.
Other companies have also had great success with FreeBSD-based systems, using them to provide high-speed Internet connectivity to remote regions. A number of remote schools using SCPS gateways to access the internet have provided excellent load testing for us, both in terms of number of simultaneous connections and sheer volume.
>Does anyone know of a commercial vendor implementing a SCPS-NP router? To take full advantage of some options in SCPS-TP, one needs as SCPS-NP router.
To which TP option are you referring? If you use NP in conjunction with TP you can do better with respect to compression, as NP specifies things like 1-byte connection identifiers (useful mostly in highly-managed situations where bandwidth is limited, like communicating with spacecraft). For TP to make use of link outage notifications, it needs some mechanism to generate and relay the notifications (not unlike cumulative ETEN, though the specification is somewhat older).
>We performed high-speed testing those SCPS options we could test and found no significant performance improvements.
>The report is being written, but not yet available. The results were presented as the 2nd Space Internet Workshop in June and will be
>presented at SpaceOps 2002.
>
>http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html
>
>Under PRESENTATIONS
>
>"SCPS-TP, TCP and Rate-Based Protocol Evaluation," (Includes multi-flow data) SpaceOps 2002 at Houston, TX, October 9-12, 2002 (Powerpoint) file size 951,808 bytes
Interesting. Slide 14 shows the rate-based theory for a 10Mbyte (80 Mbit) file transfer across a 500msec delay link. Accounting for just clocking the data (0.8 sec) and one round-trip for some sort of end-of-file acknowledgement (0.5sec) brings the maximum throughput to ~61Mbps. Perhaps the theoretical maximum was for a longer transfer and only accounted for header (and retransmission) overhead.
What's more curious is why all the rate-based protocols are down around 30Mbps, especially since it's trivial to run SCPS to 60 or 80Mbps, even on 266 to 300MHz-class machines. You say that the rate-based protocols need more work, but question anyone will immediately ask is: why? Were there losses at the network interface like you were seeing for NetBSD, or is Solaris just really slow? What do the tcpdumps show? Do the various protocols simply pause transmitting periodically, and if so, why? Are you able to push the average throughput closer to the theoretical value as file size increases? If not, why not? Obviously you've done a lot of work understanding and comparing the various protocols; maybe you could let that section of the paper leak out a bit early?
All slide 17 shows is that TCPs that assume congestion back off a lot in the face of loss. I'm curious as to why you didn't show TCP Vegas with the default source of loss assumed to be corruption. This is still 'congestion-friendly' as it will slow down when it detects queueing, but performs quite well when confronted with a lightly loaded network with moderate error rates.
As for the warning on the last slide, it should be considered in conjunction with your observation that non-congestion-controlled flows should be used only when they will not overly interfere with congestion-controlled ones. Unless one specifically chooses to disable all congestion control in SCPS, it uses rate control in conjunction with a congestion control algorithm (VJ or Vegas). This allows us to ensure that the congestion control algorithm doesn't overrun the bottleneck link rate and auto-congest the network. When using congestion control, SCPS-TP behaves like, and interoperates with, other TCP implementations, and it is appropriate for it to use IPPROTO 6. For the case when SCPS-TP is running without congestion control, it should only be used on networks where it will not interfere with congestion controlled traffic. Note that the CBQ mechanisms of Linux kernels since 2.2 (and the traffic engineering mechanisms of common commercial routers) can appropriately segregate flows.
>By the way, SCPS-TP advertises TCP's protocol number for reliable transport protocol selections. It does this even if the pure rate-based transmission is used. IMO, this is terrible as it make QoS and queue management very difficult. I may be putting a rate-based protocol into a WRED queue. Guess who loses.
>
>Will
This archive was generated by hypermail 2b29 : Fri Jun 14 2002 - 17:02:32 EDT