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

[Abhijit Sengupta]

I noticed the significant and exciting exchange of posting on March 7 and 8 
which I missed real-time (being trapped in bed with a back-pain - sign of 
old age) and here are some in-line comments.

At 3/8/2005 08:54 AM, Keith Scott wrote:
>[Greg wrote]:
> >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

What was the ambient traffic pattern? Does it match the traffic pattern we 
expect to see onboard? Because if it is not, I do not see how the 
measurement adds anything to what we are looking for.
We need to remember that a typical internet kind of traffic is not expected 
in spacecraft onboard environment where the high data rate traffic (arising 
out of camera or SAR) are usually highly predictable and precisely 
controlled through system engineering. My point being any measurement we 
want to rely upon needs to be a typical traffic distribution expected 
onboard (this reminds me of using processor speed evaluation by Dhrystone 
benchmark knowing perfectly well that flight software  are, in no way 
similar to such benchmarks).


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

Probably it will be - but that is more of a guess unless the traffic 
distribution has some similarity to onboard traffic.

>[Keith Scott]
>Why is it that we believe that TCONS is going to be able to meet much
>tighter timing requirements while at the same time providing a more capable
>service spec as ambient traffic loads pass several megabits per second, in a

I perfectly agree with Keith. In fact, I went to read the "scheduled 
service" portion in the latest version of Red Book that Greg sent me (early 
February) and did not find anything how the scheduled service works.

>box with significantly less resources?  Do we claim that the TCONS stack
>will be much more tightly integrated than TCP/UDP/IP, and that that
>integration will decrease latencies?

Who knows? As I said I could not find out how the scheduled service is 
provided.

>In testing UDP transmission delays through the stack, it would seem likely
>that the latency and jitter are introduced by interrupts (there's not a lot
>to UDP processing, especially if you turn the checksums off).  Interrupts
>will be present in the OS(s) running TCONS as well, right?  How is it that
>TCONS is going to address this?  Do we say that to meet the latency
>requirements, TCONS will be implemented in hardware/firmware and thus not be
>subject to resource usage on the 'host' system?  Is the argument that TCONS

Then we have a much bigger problem about needed hardware - compatibility 
with typical processor board etc

>can control the interrupt rate by limiting the rate at which traffic is
>allowed to impact the box?  This might be difficult to do with, say, IP
>(since it could involve limiting the aggregate rate of a number of disparate
>sources impinging on a single destination).
>
> >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.

Now I think I am as confused (what's new?). According to the previous 
sentence, if we "not need or have realtime networking requirements, then 
there is no reason to use TCONS", then we use TCONS  only for "realtime 
networking" which I presume is "scheduled service", about which I could not 
find anything that tells me how it works.

>[Keith Scott]
>Right, and I think that the only realtime TCONS service is the schduled one.
>I think that the best-effort and guaranteed services TCONS specifies will
>end up similar to TCP/UDP (since they have essentially the same service
>requirements), and that most applications, for non-scheduled service, could
>use those instead.

This brings in a very serious question - why should anyone use TCONS? The 
"best-effort and guaranteed services TCONS specifies" are similar to 
TCP/UDP (why need a new protocol?) and the "scheduled service" is unknown 
in respect of how it works.

> > >
> > > 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.
>
>[Keith Scott]
>TCONS has been specifying interoperability requirements at the service spec
>(and more specifically, the API) level, as well as protocol interoperability
>'on-the-wire'.  This allows for the highest degree of portability
>(applications and devices connected to a TCONS-compliant network should be
>able to be picked up and put on another TCONS-compliant network with no
>changes whatsoever).  At the same time it removes all choice for the
>spacecraft designer.  As above, maybe TCONS needs to be used for the
>realtime, and ONLY the realtime, services.  If this means that TCONS must
>implement the scheduled service (as I think it would), then IP will be
>perfectly happy to run over that as well as anything else.  This would allow
>TCONS (really OBL) to maintain control over all the timing and scheduling
>required to meet the realtime requirements, while allowing COTS
>plug-and-play of everything that does NOT require them.

For a network with single subnetwork, the problem is non-existent. For a 
network with several subnetworks, for example a 1553 in one - SpaceWire in 
another and a 1394 in the third subnetwork, how would this timing and 
scheduling work (recall that in 1553, an RT cannot do anything unless 
specifically commanded by BC, whereas there will be arbitration in 1394 for 
gaining access to bus and the requestor might lose arbitration and to make 
life real miserable, the SpaceWire path might be blocked because some other 
pair is using some of the links of the path)

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

What kind of measurement data is available to justify it (perhaps, we need 
to know what is this "substantial pile of software" and "moving lots of 
data" - to me they seem to be hand-waving statements.


>[Keith Scott]
>And neither will TCONS (intentionally inflammatory statement).  The point

I will probably make less "inflammatory statement" - how do we know TCONS 
will perform better?

>is, without some benchmarks of what 'a pile of software' and 'lots of data'
>are, we could argue this forever.  My fear is that we will continue to
>reject alternate solutions because they are "too heavy, too slow under high
>network load, goo slow under high CPU utilization, ..." without having any
>firm notions of what these are.  When we have finally developed TCONS to the
>point that it can be tested, if we find that it fails one or more
>performance tests used to reject other approaches, proponents of those other
>approaches are likely to be (justifiably) upset.  How do we know when we've
>won?

Rather than worrying about "proponents of those other
approaches are likely to be (justifiably) upset", I am more concerned with 
what did we achieve?
Objectively, the performance tests rejected other approaches and then it 
rejected one more approach - we are back to square one.

> >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.
>
>[Keith Scott]
>I suppose TCONS can prevent packet loss in the stack by applying
>backpressure on the application.  I'm not sufficiently famiar with the
>lower-layer interface to OBL to know how it applies backpressure to the
>network layer.
>
> >
> > > >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.

I do not agree with this conclusion - particularly without a clearer 
picture of the network traffic.
Do we have any idea of what is a reasonable traffic model for onboard 
network? If we do, what is it (I do not know myself)? If we dont (at least 
even a reasonably close approximation), using a conventional model (as used 
in typical network evaluation - evolved from a variety of terrestrial 
applications) is grossly incorrect. As a simple example, in terrestrial 
applications, network congestion can happen because users are accessing 
network in an unpredictable way (how many users are trying to access a 
search engine like Google at any instant?) while in an onboard environment, 
it is highly predictable and ordered - implying even congestion might be 
predictable.

Abhijit






________________________________________________
All personal and professional opinions in this email are my own
and do not represent, in any way, the opinion or policy of JPL
________________________________________________