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
This archive was generated by hypermail 2b29 : Fri Jun 14 2002 - 17:08:16 EDT