Keith,
With all due apologies to Sir Arthur Conan Doyle ("The Sign of Four"):
"It is UDP," he said, "a seven-per-cent solution.
Would you care to try it?"
UDP doesn't help to avoid *any* of the problems of TCP, it just moves
them to something above UDP. You will still need to build the required
subset of:
{sequencing, reordering, flow control, congestion avoidance,
reliability, etc.}
into a "standard" application - or applications.
If, for a particular task, the required subset of the above is indeed
the null set (and as you note, data broadcasting is one such deployment),
UDP is an excellent choice for an IP-based implementation of that
particular application - but this really is not the model that most
people fall in love with when they first hear the siren's song of
"Internet in Space"...
> The bottom line is we want to use standard IP/UDP/TCP protocols
> that are supported in every operating system available.
You desires are as valid as anyone else involved; It has been said
many times before, it's the prerogative of any given mission to choose
their desired communications model and supporting mechanisms.
As for "IP/UDP/TCP protocols that are supported in *every*
operating system available" - that's not demonstrably true is it?
"Supportable" absolutely, universally supported - not quite.
We can name some cases where support had to be added to an OSes,
so the distinction is:
"IP/UDP/TCP protocols that *can* be supported in *every*
operating system - period."
This is the case for *any* layer four protocol.
Whether or not a particular layer four protocol *needs* to
be supported by a particular operating system depends on
the assumed communications architecture (see next)
> I have seen people attempting to fix TCP for all sorts of special
> cases for years and still don't see much convergence.
In all fairness, I've also seen people providing reliable services
over UDP for many more years, and still there is no convergence;
I don't consider a lack of convergence a bad thing :o)
> Using a modified TCP requires more software support that creates
> more problems when you are building and deploying operational control
> centers and level-zero processing systems.
I respectfully disagree - any UDP-based solution clearly requires
some sort of applications software; How is the deployment of this
application software any more complex than the deployment of something
capable of handling TCP (which can be application software or a tiny
box with two 100BaseT ports, etc.)?
Further, if we are going to the trouble to encapsulate the spacecraft
traffic in IP datagrams - I would imagine that the desire is to
*eliminate* the level zero processing and to route those IP datagrams
directly to the principle investigators...
What role must the control centers have in the end-to-end data flow
for this operational model?
> We really prefer to use standard protocols at layer 4 and below and
> do any space specific tweaks in the application layer.
That's certainly a position that could be advocated - to help move that
notion forward you need to get people to converge on a full solution:
an application layer protocol (and it's interface) so that people
can build the same sort of diverse applications set that they have
available to them over stream and datagram sockets.
As silly as the notion is to *me* (and I DO think it to be silly),
the people who demonstrate the greatest support for the concept of
"IP in Space" have expressed interest in supporting things like telnet
and http between their spaceborne instruments and their ground-based
infrastructure. These - and many of the other services people commonly
associate with an "Internet experience" are TCP-based.
Unless we can build and (widely) deploy UDP-based alternatives to these,
UDP-based solutions remains a "seven (or [1..9]7 percent solution".
So, while UDP is part of an IP-based solution set, it is not sufficient.
Eric
Keith Hogie wrote:
>
> All,
>
> I have been following the discussion on Satellites running IP and it
> seems to have gone off heavily in the TCP direction. I realize this is
> the TCPSAT group but the question seemed to be broader than just TCP.
>
> What we see for missions using IP is a very heavy use of UDP and not
> TCP. TCP will always have limitations that we feel are best avoided
> by using UDP. This allows us to do things like data transfers over
> one-way links which does not work with TCP. I have seen people
> attempting to fix TCP for all sorts of special cases for years and
> still don't see much convergence.
>
> For an example of other UDP use see the following:
>
> http://www.esa.int/export/esaCP/ESALS5OED2D_index_0.html
> http://www.gcs-salzburg.at/
> http://www.gcs-salzburg.at/products/p_odg.html
> http://www.simple.at/
> http://www.datacast.at/technology.html
>
> We are looking at the MDP/NORM UDP-based file transfer protocol and
> plan on using it to transfer files from the Space Shuttle payload
> bay on STS-107 (scheduled to launch on July 19th but may be slipping
> right now).
>
> The bottom line is we want to use standard IP/UDP/TCP protocols that
> are supported in every operating system available. Using a modified
> TCP requires more software support that creates more problems when
> you are building and deploying operational control centers and
> level-zero processing systems. We really prefer to use standard
> protocols at layer 4 and below and do any space specific tweaks
> in the application layer.
>
> ----------------------------------------------------------------------
> Keith Hogie e-mail: [email protected]
> Computer Sciences Corp. office: 301-794-2999 fax: 301-794-9480
> 7700 Hubble Dr.
> Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/Goddard
> ----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Jun 26 2002 - 12:47:07 EDT