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

[gregory.menke at gsfc.nasa.gov]

 > Hi Greg,
 > thanks for your comments...
 > 
 > >Actually I am not planning to use IP for carrying real-time, bounded latency
 > data flow. Nevertheless, I am not aware of any study that technically proves
 > that IP is not feasible for SOIS, specially because the "realtime, bounded
 > latency requirements" that you mention are not clearly specified. If you do,
 > 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 propose
 > 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 practice
 > would be to group all the possible realtime constraints into categories of
 > severity and see how many can be met by using existing COTS standards within
 > TCONS.

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
idiosyncratic.

 
 > >Other questions that comes to my mind are:
 > 1. Are most of the people claiming for SOIS-TCP/IP interested in the TCP API
 > 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.

Greg