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

[Chris Plummer]

Guys, not surprisingly this diagram has reopened the discussion on a whole
bunch of diverse issues that we need to get a handle on. Some of these are
things we've seen before, some are new, but I think all of them are
important.

I have glanced over most of the e-mails as they arrive and have had
conversations with Max and Abhijit about some aspects of some of the issues,
but it is clear that this thread could run on in several different
directions for a good while now. However, with so many different issues
wrapped up in one thread there is a danger that we may go off at tangents or
overlook something important. Therefore, what I am intending to do is to
take some time in the next day and a half to look over the thread and try to
summarise what I think are the key issues and the various positions in a
short note. Based on this, and once we all agree that it represents all of
the issues fairly, I think we can spawn a new series of threads to tackle
each individual issue. Hopefully, as well as bringing all of us to consensus
over the issues, this will also provide us with text and graphics for both
the green book and the web site.

On the subject of the web site, Max and I were a bit busy today on the SOIS
test bed activity, but we have agreed to collate all of the inputs received
so far and to make an update to the site on Monday afternoon.

In the meantime, feel free to keep this thread alive with further
contributions.

Cheers,
        Chris.

-----Original Message-----
From: sois-tcoa-bounces at mailman.ccsds.org
[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of
gregory.menke at gsfc.nasa.gov
Sent: 03 March 2005 21:55
To: Abhijit Sengupta
Cc: 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)


Abhijit Sengupta writes:
 > At 3/2/2005 10:24 AM, gregory.menke at gsfc.nasa.gov wrote:
 > >That the implementation supplies the given service interface and
 > >supports the given protocols.
 > >
 > >If an implementation has a different service interface, but supports
 > >the given protocols, then it is protocol conformant and not fully
 > >SOIS-compliant.
 > 
 > "given protocols"? Which protocols?

The protocols defined in the TCONS standard.


 > 
 > > > In my view, I do not feel like precluding system designers the 
 > > possibility of
 > >  > experimenting different transport and network layer protocols for
 > >  > implementing "the same" SOIS standard services; this is why I think
that
 > 
 > I perfectly agree - that's why I was insisting all along for definition
of 
 > what kind of service is expected from transport and network layers, 
 > what  the transport layer at one end expects from the transport layer
from 
 > the other end and the data structure needed for that  (basically PDUs) .
If 
 > someone can come up with a different transport and network layer
protocols 
 > that can support the SOIS application layer services then I wonder why 
 > these protocols should be precluded. I think we need to focus why we are 
 > doing all these - we are not in the process of defining a set of  new 
 > protocols for onboard usage just for the heck of it, the objective is to 
 > reduce the development cost, improve reusability by providing services
and 
 > to support the services we need protocols to support the services at
lower 
 > level from the application layer.

No new protocols are precluded.  New protocols can be added in exactly
two ways without breaking TCONS;

1- on top of the best effort service, where the new protocol benefits
   from the network layer abstraction that TCONS provides, and adds
   its (presumably useful) semantics to the best effort service.

2- as a new service interface and protocol integrated into TCONS.

When a new protocol is plunked down on top of the OBL, which is what
Max is proposing with his picture, then TCONS can no longer guarantee
its services, because it is no longer in control of the datalinks.
This is the fundamental reason why we propose that new protocols be
developed on top of the TCONS services.  It is exactly the same reason
why new protocols are typically built on top of UDP instead of on top
of ethernet drivers- or even as new IP protocols.


 > 
 > >  > TCP/UDP SCPS-TP IP etc. should be left in the diadram even if some
minor
 > >  > graphical changes are required (will explain later why).
 > >  > The problem arises when we start to link protocol to service
interfaces. I
 > >  > doubt that TCP/IP can fullfill ALL the requierments of SOIS
services.
 > >  > In particular, how can TCP/IP guarantee a scheduled/time-constraint 
 > > delivery
 > >  > of data onboard the spacecraft ?
 > 
 > Okay, I have seen this reference "TCP/IP cannot guarantee a 
 > scheduled/time-constraint delivery
 > of data onboard the spacecraft" quite often and I still fail to see the 
 > rationale behind it. Would someone volunteer to elaborate on it - perhaps
a 
 > comparison with  TCONS will be helpful.

TCP cannot provide reliablity or latency control within the kinds of
timeframes flight software often needs.  It routinely allows timeouts
to occur in the order of seconds and even minutes, retry logic allows
data transfer latencies to extend to similar timeframes without timely
notification of the application layer, and TCP doesn't provide any
sort of reasonable latency bounding guarantees.  Some IP stacks are
designed to do better in these situations, but a least common
denominator IP stack does not make any particular efforts to do so-
and the "realtime" ip stacks still don't control those issues as
completely as flight software sometimes needs.

Even if all IP stacks that might plausibly fly were to essentially
provide features to control these kinds of issues, then there is still
the problem of bandwidth scheduling to solve.  TCONS's purpose in life
is to handle requirements related to these issues- and be a lot more
efficient with cpu-time than IP stacks are.

In some cases TCP will work fine in a flight application, in others
there is no way it can ever work.  TCONS is attempting to address the
latter case without precluding the former- that is why we show the IP
stack as a user of TCONS, presumably it would be mapped onto the best
effort service.

This question has been raised at each of the last few meetings,
Abhijit- and we've been making the same argument each time.  Is there
some way we could clarify it?


 > 
 > >I don't understand why there is an issue with the relation of link
 > >protocol to service interface- could you clarify that please?
 > 
 > I think when Max said "to link protocol to service interfaces", he meant 
 > "to relate protocol to service interface" ("link" here does not mean
"data 
 > link")

OK, let me try again.  I don't understand why there is an issue with
the relation of protocol to service interface- could you clarify that
please?

 
 > >  > In other words, TCONS wg is working on the reccommendation of a
standard
 > >  > service interface as well as the 'ideal' protocol definition for 
 > > carring on
 > >  > ALL such services in the best way possible (hopefully); if a system 
 > > designer
 > 
 > Once again I am somewhat confused here (perhaps I get confused quickly) -

 > what service interface are you referring to?

The TCONS api.



 > >  > Furthermore, the protocols used within the TCONS box can be whatever
 > >  > combination of TCONS, TCP/IP, UDP/IP, SCPS/TP or any X-PROTOCOL
still 
 > > to be
 > >  > invented !!
 > 
 > I agree with Max's comment - also I did not follow what Greg meant.
 > 
 > >All these protocols should be implemented on top of the best effort
 > 
 > Why?
 > 

Because if new protocols interface directly to the OBL, TCONS can no
longer control media access and therefore cannot guarantee it is able
to deliver on its requirements.  

For example, assume you have a realtime IP stack on top of a realtime
network, providing realtime data transfer with some well-defined
latencies.  Now (somehow) add your new, experimental protocol stack
alongside the realtime stack, sharing its datalinks.  How does the
realtime stack continue to deliver realtime services?  Or, do you put
your new experimental protocol on top of the realtime stack's UDP
transport so you can integrate your traffic without disrupting the
realtime traffic?

Gregm



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