Will:
Last week you provided a link for your results of your high-speed
SCPS and rate-based protocol testing which you will be presenting at
SpaceOps 2002:
"SCPS-TP, TCP and Rate-Based Protocol Evaluation"
I've spent the past few evenings going over the briefing
material and there appear to be several troublesome aspects of the
data curves which could lead to a suspicion that some of the measured
data may be flawed. Summaries are provided in [footnote 1]. In there
even that there is any merit to them, there should be ample time to fix
any problems prior to SpaceOps..
In spite of these possible discrepancies, an impartial examination
of the provided performance curves could in fact lead to a surprisingly
upbeat assessment of the performance of all the protocols.
Conclusions can be drawn that would be in stark contrast to those
provided in slide 20 of the presentation - which is transcribed for
reference in [footnote 2].
I am offering the following set of alternative conclusions and invite
interested parties on this mailing list to independently analyze the
results and comment back.
Eric
The *complete* text including the footnotes has been placed at:
http://www.ipnrg.org/travis/Peer_Review/GRC_SpaceOps2002.txt
=======================================================
An alternative set of conclusions drawn from the data presented at:
http://roland.grc.nasa.gov/~ivancic/papers_presentations/SpaceOps2002_TCP_SCPS.ppt
1 Depending on the mode of operation, even very small
transactions such as spacecraft command and control
traffic *may* indeed see a benefit from using a
rate-based protocol
2 Rate-based protocols are advisable for *any* environment
where bandwidth reservation is practical and available.
3 The performance problems experienced with the rate-based
protocols was most likely due to accidental misconfiguration
of the protocols, causing them to congest the network.
4 With proper configuration, all the rate-based protocols
could have performed better in the errored environments.
- An increase in error frequency has the same effect as
increasing the rtt, and hence changes the bandwidth/
delay product
- The measured curves illustrate the effects of window
limiting rather than the expected error performance
curve decay
- The buffer sizes used on the rate-based TCPs and MDP
should have been re-tuned to reflect the effective
bandwidth-delay product
5 The single stream and multi-stream test results clearly
illustrate that the SCPS enhancements to TCP provide
measurable performance improvements over the TCP SACK
implementation tested.
- The value of these performance increases is
subjective and would need to be judged on a
mission by mission basis
6 Even with equal performance, the deployment of a
rate-based TCP is more desirable than the deployment
of MDP or other non-TCP protocols when unicast data
delivery is the goal.
- The rate-based TCP is a sending-side only modification
- All "standard" TCP applications can be deployed
without modification
7 While the space community should be aware of current and
future TCP research, the existing standard protocols and
capabilities (drawn from a variety of communities) appear
to satisfy all known mission needs.
This archive was generated by hypermail 2b29 : Thu Jun 20 2002 - 21:41:55 EDT