[Sois-tcoa] [Sois-tcons] RE: reference model (2 levels ofSOIS-compliance)

Chris Plummer c.plummer at skynet.be
Tue Mar 8 06:13:53 EST 2005

Here attached is my quick précis of this thread and the issues arising from
it. I'm bound to have missed something that is dear to one or more of you,
so feel free to correct me. None-the-less, to my mind there are at least
five separate issues arising from this discussion, each of which deserves
its own thread. If everybody is happy with this, then let's kick off some
more specific threads.


-----Original Message-----
From: sois-tcons-bounces at mailman.ccsds.org
[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of
gregory.menke at gsfc.nasa.gov
Sent: 07 March 2005 22:55
To: Massimiliano.Ciccone at esa.int; sois-tcons at mailman.ccsds.org;
sois-tcoa at mailman.ccsds.org
Subject: Re: [Sois-tcoa] [Sois-tcons] RE: reference model (2 levels

 > Hi Greg,
 > thanks for your comments...
 > >Actually I am not planning to use IP for carrying real-time, bounded
 > data flow. Nevertheless, I am not aware of any study that technically
 > that IP is not feasible for SOIS, specially because the "realtime,
 > latency requirements" that you mention are not clearly specified. If you
 > please let me know.

We did simplistic measurements of selected UDP rx and tx transit time
from app layer to hardware on a 233mhz PowerPC.  Packet traffic
experienced delays up to 5ms when ambient traffic loads approached
several megabits/second.  The latency SD was quite large, though the
minimum was acceptable.  On a flight processor running 100mhz or so,
possibly without L2 cache and with limited memory, the situation will
be much worse.

The previous generation of GSFC spacecraft have packet transit latency
requirements of less than 4ms.  System designers are not going to
accept an increase in maximum packet latency even after clock rates
increase by a factor of 10.

Once again, if a spacecraft does not need or have realtime networking
requirements, then there is no reason to use TCONS.

 > If you do have a protocol stack in mind that can meet those kinds of
 > requirements, then it should be merged into TCONS so it is another
 > protocol choice for the system designer.
 > >No, I don't. But I bet that we will meet a lot of people willing to
 > different protocol stacks to be used within TCONS.

OK, let them put their protocol specifications on the table and
indicate the protcols cannot be transported by TCONS and must instead
supplant it.

Otherwise, we have to get on with making implementations or we're just
wasting time.  We've been studying the issue for a couple years now
and other candidate protocols have never been presented.

 > If you do not, and replace the TCONS transport/network layers with
 > some other protocol, then I hope you are prepared to do all the work
 > to make it sufficiently realtime and low overhead so the TCONS service
 > interface guarantees can be met.
 > >What do you mean by "sufficiently realtime" ? Every mission has its own
 > realtime constraints. We never defined them in a clear way. A good
 > would be to group all the possible realtime constraints into categories
 > severity and see how many can be met by using existing COTS standards

For a general measure, anything we implement should offer no worse
realtime properties than existing systems, so you can view a
worst-case device-to-application latency of 4ms as "sufficiently
realtime".  "Realistically realtime" should offer latency of no more
than 1ms.  On a 100mhz PPC, running a substantial pile of software and
moving lots of data, an IP stack cannot reliably meet either limit.

You <might> be able to tweak some IP stacks on some processors to do
so, and limit application access to the IP stack to ensure packets are
not lost and buffers not overloaded, but such a solution is inevitably

 > >Other questions that comes to my mind are:
 > 1. Are most of the people claiming for SOIS-TCP/IP interested in the TCP
 > to be available to space applications ?
 >  or
 > 2. are they only interested in havin TCP/IP behaviour "within" SOIS for
 > end-to-end interoperability ?
 >  or
 > 3. both ?

Beats me.  I don't care about TCP in this situation.  Its not a
realtime protocol, its standard timeouts extend far to long, it does
not handle or recover or indicate link failure in a manner or time
interval that flight software requires.  It would be fine for
non-realtime and non-critical use, but not as a fundamental part of
flight software operations.


Sois-tcons mailing list
Sois-tcons at mailman.ccsds.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Reference model and all that.pdf
Type: application/pdf
Size: 34700 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050308/910afd2d/Referencemodelandallthat-0001.pdf

More information about the Sois-tcons mailing list