SCPS-TP, TCP and Rate-Based Protocol Evaluation

[Eric Travis <[e-mail]>]

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.