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

Fri Mar 4 11:43:15 EST 2005

Hi all,

Greg wrote:
"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."

I think I need clarify my position a bit better here.
In the picture I proposed, the presence of TCP/IP, SCPS-TP and other
protocols within the TCONS frame (i.e. in parallel to TCONS protocols) does
not mean that there can be two network protocols operating in the same SOIS
stack. I agree when Steve, Greg and Jane say that it is not possible to have
two different Network layers in a single SOIS implementation, doing so would
compromise the efficiency and the operation of the TCONS services. Yes, the
TCONS Network layer cannot exist "alongside" IP.
My point is that a system designer might want to choose and use its own
network protocol if he/she feels that they can meet the performance
requirement for the specific mission, for example IP, INSTEAD of the TCONS
network protocol and, in the same way, use UDP INSTEAD of the TCONS
BEST-EFFORT protocol (they do not differ too much anyway).
Now, if this protocol substitution is done by keeping the same "service
interface" exposed (and reccommended) by the TCONS layer to the Application
layer, then this particular SOIS implementation will only be SOIS-compatible
from a "service interface" point of view, but not interoperable with a
fully-compliant SOIS implementation which implements the reccommended TCONS
Transport (Best-Effort)and Network protocols together with the TCONS-defined
service interface (also called Service access points).
This means that the application layer sw developed for the half-compliant
SOIS system can still be re-used by another fully/half compliant SOIS system
!!

Now if there is the need of operating a TCP/IP-based application over a
fully-compliant SOIS stack (that is exposing the TCONS service interface and
implementing the TCONS Transport and Network protocols) than the data flow
generated by this application (i.e. IP datagrams) must be encapsulated within
the TCONS BEST-EFFORT service (or even directly within the TCONS Network
protocol ??) and not exist as a network data flow 'parallel' to TCONS. This
in order to guarantee complete control on the requirements of TCONS Transport
services.
In other words, I see TCP/IP (for example) can be operated in two different
ways within a SOIS environment:
   As part of the TCONS stack (if no TCONS protocols are used)
   Related to an onboard TCP/IP based application and encapsulated over the
   TCONS stack (TCONS transport and network protocols)

Looking forward to your comments
Have a nice week-end

Max

                      gregory.menke at gs                                                                                                               
                      fc.nasa.gov              To:      Abhijit Sengupta <Abhijit.Sengupta at jpl.nasa.gov>                                             
                                               cc:      Massimiliano.Ciccone at esa.int, sois-tcons at mailman.ccsds.org, sois-tcoa at mailman.ccsds.org      
                      03/03/2005 09.55         Subject: Re: [Sois-tcoa] [Sois-tcons] RE: reference model (2 levels of SOIS-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