Re: SCPS-TP, TCP and Rate-Based Protocol Evaluation

[William Ivancic <[e-mail]>]

At 09:29 PM 6/20/02 -0400, Eric Travis wrote:
>Will:
>
>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
>

Thanks for the input.  I will definitely incorporate much of this.  See 
below for a few comments.


>An alternative set of conclusions drawn from the data presented at:
>
>http://roland.grc.nasa.gov/~ivancic/papers_presentations/SpaceOps2002_TCP_S 
>CPS.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

Will Include

>2 Rate-based protocols are advisable for *any* environment  where 
>bandwidth reservation is practical and available.

Will include with as:  Rate-based protocols may be applicable 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.

I wish this were the case,  but we configured and tuned these to the best 
of our capabilities and consulted with the developers (Mitre, NRL, 
etc...).  The problem appears to be (at least for MDP) that the receiving 
system choked.  It can not process fast enough due to the algorithm and 
implementation of the protocol.



>
>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


Same comment as for item 4.  We tuned these for best performance at Zero 
BER.  It is impractical to expect one to constantly, manually  tune a 
protocol for a given time-varying unknown link condition.  We believe our 
tuning was valid for today's protocols.  That being said, I believe work 
needs to be done for autotuning as I believe it is impractical and 
unreasonable to expect the general users of systems to possess the 
knowledge to tune each protocol for a particular environment.   Obviously a 
research area with lots of work being done here.

>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

Will includes something along these lines.


>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

Well, I don't consider a pure rate-base, not congestion control protocol 
TCP for reasons I previously stated - even though the protocol header is 
the same as TCP.  However, an in-kernel reliable rate-based protocol may be 
more desirable for unicast data than an application level rate-based 
protocol.   There is definitely room for debate here.   This is a 
philosophical debate.  I see merit on both sides and I don't really care to 
carry on such a debate here.  IMHO, neither answer is right or wrong and 
both are right and wrong depending on the situation.

I'll consider this, but I definitely cannot accept it as worded.



>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.
>

Nice touch, I'll add this.






=======================================
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