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

[Abhijit Sengupta]

At 3/4/2005 08:43 AM, you wrote:

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

Of course. I do not see why anyone in their right mind would have two 
different protocols would existing in the same layer. The problem seems (at 
least to me) to originate from the fact that TCONS do not specify a 
protocol for transport layer and one for network layer. It seems to me 
(correct me if I am wrong) that TCONS is defining a package deal - take 
both the protocols defined for transport layer and network layer or take 
none. If we look at it pragmatically, we need interoperability - otherwise 
no one will be interested no matter how sound or elegant the protocols are. 
In transport and network layers, for interoperability, we have two choices, 
(when I say TCP I mean TCP or UDP)
(1) either we say TCONS provide the protocols and those are the only 
protocols that can be used for transport and network layers and nothing 
else - then we need to provide TCP and IP functionalities in them to 
justify that if any user is perfectly happy with TCP/IP, TCONS protocols 
provide that;
(2) or user can choose TCONS transport protocol or TCP for transport layer 
and TCONS network protocol or IP for network layer. In this case, the TCONS 
transport layer at one end should be able to talk to TCP at the other end 
(similar is for network layer). If this does not happen, SOIS is highly 
likely to lose interest.

>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 clearly brings in the old question what you asked before "what does 
SOIS-compliant mean?"
SOIS-compliance (in my opinion) also includes interoperability. In the 
reference model, if we put a set of boxes box1, box2, ..., boxn in a layer, 
to me it implies that any of the boxes box1, box2, ...boxn can be used for 
the service in that layer and nothing else. These boxes should be able to 
talk to each other to preserve interoperability - if they cannot, there is 
lack of interoperability and hence lack of SOIS-compliance.

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

Yes, possibility it can be reused - however, testing is expected to be a 
nightmare because the transport layers do not understands each other's 
language.

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

I thought it should be other way round, where TCONS datagrams be 
encapsulated within IP datagrams because at IP level it wont be known how 
to handle TCONS datagrams.

Abhijit


> 
>
>                       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
>
>
>
>
>
>
>
>
>_______________________________________________
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcons



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