Is SCPS an IETF RFC on a standards track yet?
At 05:08 PM 6/14/2002, Eric Travis wrote:
>Will,
>
> >On Thur, 13 June 2002, 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?
>
>Ah - there is just so much of your old baggage here...
>
>You responded:
>
> > Does anyone know of someone "flying" an onboard SCPS stack?
>
>Outside of shuttle/station, the number of platforms that have
>flown a SCPS stack for onboard use is the same as those that
>have flown a native Internet protocol stack. Actually, the
>number of "SCPS compliant missions" is double that because
>the native Internet protocol stacks are SCPS compliant
>(This is no accident, as we were the *original* proponents of
>IP deployment on space vehicles - when it made sense to do so)
>
>If your intent was to argue to be that this makes "SCPS"
>(again, which includes TCP, UDP, ICMP, etc. and IP) impractical
>for space deployment, please do proceed down this path. The rope
>is approximately the right length...
>
>But none of this is not what Lloyd asked is it?
>
>The answer to Lloyd's question is :
>
> Yes
>
>CCSDS's did the pioneering work into onboard IP based networking
>(a free clue - this was the SCPS effort), a stack was flown over
>6 years ago and it did splendidly. Despite these now ancient
>accomplishments, no missions care then, and even now missions just
>don't need IP and wouldn't benefit from it. Maybe someday...
>
>Since spacecraft, link and ground infrastructure are certainly
>capable of supporting IP (as I said, we did it 6 years ago without
>disturbing a thing)... just maybe there are reasons for the dearth
>IP deployment on spacecraft to date?
>
>Therefore for everyone's benefit, would you please:
>
> Name one mission that failed because of the lack of an
> IP protocol stack across the spacelink?
>
> Name one mission that returned less science because
> it wasn't "IP enabled"?
>
>IP on the ground distribution network seems to be satisfying
>all the needs so far - when it makes sense to extend it over
>the spacelink, it'll happen.
>
>Spacecraft designers are notoriously conservation folks,
>and I don't believe it is difficult to understand why.
>
>I would actually love to see an large IP-based science mission
>flown as we'd learn some interesting things about the communications
>problems. I've been waiting about a decade for this. You new-age
>"IP zealots" are latecomers :o)
>
>Please just get over it and let's advocate the spending
>of NASA's funds on actual scientific pursuits rather than
>'kewl things to do with Internet stuff'.
>
> > Does anyone know of any commercial applications that call the
> > SCPS-TP options. SCPS-FP is the only application one I know of.
>
>Ummm... Why would you think that an application *needs* to call
>socket options just because they exist? I think you would lots
>of commercial applications that don't call TCP options. This
>proves what?
>
>I'd be surprised if most "commercial applications" need to call the
>SCPS specific TCP options. If it would be beneficial to the hosted
>applications, chances are the system would be configured to use them
>by default.
>
>Just to set you straight, every "commercial" TCP application that
>you would ever want to use works just fine over "SCPS-TP" (read: TCP),
>I do it all the time - but I don't expect it really matters or
>that anybody really cares.
>
> > 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.
>
>This is certainly new information to me.
>
>Exactly which TCP behavior enhancements *require* SCPS-NP and
>this can not be provided over IP?
>
> > We performed high-speed testing those SCPS options we could test
> > and found no significant performance improvements.
>
>Depending on the conditions under which you tested, that probably
>wouldn't surprise me at all. Of course, you aren't claiming that
>your (yet undocumented) tests are conclusive - are you?
>
>Do you have any non-Powerpoint versions of your results?
>I'd love to see your results - but more so I'd love to read
>the technical paper that generated them.
>
>Often when running my traffic over the Internet, I also see no
>performance increase when I'm running a TCP with the SCPS defined
>enhancements - I see no performance degradation either.
>
>However, when I run across more challenged paths (say those that
>include satellite hops), then I certainly do see 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
>
>Hmmm... hopefully the paper will be finished before you present the
>results again. I'm looking forward to reading, commenting on the actual
>report.
>
> > 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.
>
>Well, if someone is foolish enough to stick metal pots into a microwave
>oven, guess who loses? Obviously this makes metal cookware terrible for
>deployment in any kitchen environment.
>
>IMO, you are a bit confused here. Exactly what are you expressing a concern
>about here - that it is possible for people to make stupid configuration
>choices?
>
>There are certain configuration options that only make sense if you
>*know* the characteristics of your entire end-to-end path. Isn't it
>obvious to you that choosing pure rate-based transmission obviously
>fits into this category?
>
>The rule is darned simple:
>
> If you do not have an end-to-end bandwidth reservation,
> you are foolish (if not just evil) to configuring
> flows to run with only rate-pacing.
>
>The reason that an intelligent person would even consider running
>in a purely paced manner is when they have arranged to have reserved
>capacity for the flow *over the entire end-to-end path*.
>
>If it is unreasonable for you to have this guarantee, then it is
>unreasonable to be running without any other congestion mechansims
>active.
>
>Given that you have to actually do work to force this configuration
>one would guess that a clueful network administrator and end-user
>would make sure that this makes sense with whatever else was going
>on in the end-to-end path.
>
>If you are upset that you can't make queuing decisions based on a
>simple check of a protocol ID rather than observed flow behavior,
>then be happy to have learned something useful outside the parameters
>of the satellite universe.
>
>Not all TCP flavors/implementations have the exact same mechanisms - and
>the evolution and divergence in behavior is likely to grow over time.
>Even subtle differences in behavior might want to influence your queuing
>decisions. Further, there is nothing preventing anybody from hacking a
>TCP implementation to exhibit antisocial/greedy behavior.
>
>Making decisions on *assumed* behavior is ultimately going to be the
>wrong choice and not going to yield the desired results. Police flows
>on actual - not assumed - behavior.
>
>A robust network can't "trust" its users to be nice, honest and never
>attempt to consume more resources than they are due. Making such decisions
>based on a label generated by the end-user entity (even a protocol ID)
>is just a bad idea.
>
>Having managed capacity down to the granularity of individual flows
>is quite reasonable in a space mission environment. This is the
>intended use of purely rate limited TCP streams. If someone chooses
>to misuse this capability, hopefully the flow will be suitably punished
>for it's non-TCP friendly behavior over shared paths (just as should
>any purely rate-paced UDP traffic).
>
>If you are trying to express a desire to be able to transparently
>multiplex returned mission science data with traffic like e-mail
>over a common IP backbone... You would run the very real risk having
>to retransmit the science data over the spacelink because of terrestrial
>congestion... that would be an excellent example of a silly configuration
>decision.
>
>Eric
Dan Shell
Network Architect
CISCO Systems
Gobal Defense and Space Group
Wireless/Mobile Networking/ Satellite
216 643 2422
This archive was generated by hypermail 2b29 : Tue Jun 18 2002 - 08:39:20 EDT