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

[Chris Plummer]

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.

Chris.

-----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
ofSOIS-compliance)



 > 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




_______________________________________________
Sois-tcons mailing list
Sois-tcons at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sois-tcons
-------------- 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