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

[Abhijit Sengupta]

At 3/2/2005 10:24 AM, gregory.menke at gsfc.nasa.gov wrote:

>Massimiliano.Ciccone at esa.int writes:
>  >
>  > Dear all,
>  > Sorry for the late answer but I got the flu and come back to work only 
> today.

Hey Max, I hope you are feeling better now.

>  > First of all I would like to remind you all to use the formal channels of
>  > communication (i.e. ccsds mailing list) in order not to remain 
> 'invisible' to
>  > the secretariat.

That's a very good idea.

>  > Second, I noticed that the choice of the reference diagrram model 
> raised some
>  > very critical questions that have been dragged for long time.
>  > One in particular, above all, is:
>  > What does SOIS-compliance mean ?

At a higher level, to me, SOIS-compliance means the system design satisfies 
the requirement of SOIS in terms of software reusability. If you refer to 
the word document I sent yesterday, I tried to elaborate under what 
condition I think a design is not compliant.


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

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

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


>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")

>  > 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?
A protocol definition at any layer supports interface service to upper 
layer and needs interface support from lower layer. The application layer 
defines the services and interfaces needed and TCONS is expected (at least 
that is what I think) to define
(a) what information are to be exchanged by the transport and network 
layers at two ends
(b) what services are needed from OBL (or OBLAN?) to support that.


>  > decides not to use TCONS but other protocols instead, then the resulting
>  > system will lose interoperability with other systems implementing 
> TCONS but

Whether it loses interoperability depends on what the transport layer 
protocol is. That is precisely why I was bugging quite often to know what 
information the transport layer (for example) at one end needs to that at 
the other end. If the answers are known for the (a) and (b) above I do not 
see the interoperability problem.

>  > it will still meet the requirements for being SOIS-compliant at the 
> SERVICE
>  > INTERFACE level.
>
>I agree with Steve as well.  IMO, the TCONS network and transport
>layers are fundamentally necessary to meet the qualities of service
>that TCONS provides.  By putting the IP stack in as a peer protocol
>directly exploiting OBL features, all you achieve is compromising the
>benefits of TCONS; in this case the unification of disparate datalinks
>into a single address space and per-frame guarantees of reliability
>and timeliness.  If you're thinking about the expansion of TCONS
>services, providing something new, then the new service should at
>least be interfaced to the TCONS network layer if its somehow
>infeasible to implement on top of one of the existing TCONS
>transports.
>
>I think a lot of this argument depends on what "not using TCONS"
>means.  If it means the existing services aren't sufficient, then why
>is it necessary to implement other stacks on top of the OBL layer?
>Experimental protocols should be built on top of the best effort
>service, the same way all sorts of protocols are built on top of UDP-
>its a purposefully thin shim on top of the network layer intended to
>make augmented transports easier to develop without masking or
>distorting network layer properties.
>
>If some new experiemental transport turned out to be something widely
>useful, then I imagine it would be enshrined into TCONS as a new
>service- with a well-defined relationship to the rest of the TCONS
>transports.  When you put things like IP stacks in the pictures as
>peers of the TCONS network and transport layers, I think it
>oversimplifies the question and implications.
>
>I believe we are also doing more than specifying an "ideal" protocol,
>we are specifying THE protocols.
>
>
>
>  > 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?



Abhijit

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