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

[Chris Plummer]

Keith wrote:
    ....we could argue this forever.....

And we probably will unless we actually start prototyping and comparing
back-to-back TCONS with alternative protocols. Besides, we will make our
case stronger if we demonstrate that we can support other protocols in
addition to TCONS.

Keith wrote:
   ... OBL can do the arbitration, right?  OBL should, I think, know darned
well what the protocol asking for services is (OBL has a next protocol
identifier, right?  Or does OBL only support TCONS network service?)....

... There was conceptual agreement at the SIS/SOIS plenary in Montreal
(Dai's
slide) of allowing TCONS to coexist side-by-side with something like IP.
This would put the burden on OBL to schedule the realtime traffic while at
the same time providing access to the non-scheduled parts of the link to
other network technologies (like IP).  This was deemed perferable to forcing
IP to run over TCONS (scheduled) service, which would seem the other option.

I also remember at the time that several of us gathered around that picture
and said "that looks like good protocol engineering". So gentlemen, let's
get on and do some good protocol engineering. Let's set ourselves the task
of implementing both TCONS and some other protocol (SCPS maybe?) over OBL
and resolve this discussion once and for all.

Chris.




-----Original Message-----
From: sois-tcoa-bounces at mailman.ccsds.org
[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of Keith Scott
Sent: 08 March 2005 17:55
To: gregory.menke at gsfc.nasa.gov; 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
levelsofSOIS-compliance)


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

[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
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?  

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

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

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

[Keith Scott]
And neither will TCONS (intentionally inflammatory statement).  The point
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?

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



>Greg
>
>
>
>
>_______________________________________________
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcons
>




_______________________________________________
Sois-tcoa mailing list
Sois-tcoa at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sois-tcoa