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

[gregory.menke at gsfc.nasa.gov]

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