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 +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger ID: ivancic
http://roland.grc.nasa.gov/~ivancic
This archive was generated by hypermail 2b29 : Fri Jun 21 2002 - 11:03:54 EDT