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

[gregory.menke at gsfc.nasa.gov]

Abhijit Sengupta writes:
 > At 3/4/2005 08:43 AM, you wrote:
 > 
 > 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

There are network and transport layers, best
effort/guaranteed/scheduled are transports, on top of the network
layer that homogonizes the address space.  Only transports enshrined
into TCONS get to talk to the network layer.

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

Please explain why someone would choose an IP network layer when
realtime, scheduled and guaranteed network performance is required.

Vanilla IP stacks <cannot> meet realtime flight network comms
requirements.  You might be able to find one that sort of does and has
a pile of non-standard junk alongside to handle scheduling, but the
whole thing will be proprietary and probably unavailable for many
architectures.

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

It means an implementation has a conformant API and implements
conformant on-wire protocols.

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

Because IP cannot reasonably be considered a realtime networking
protocol.  If realtime/bounded latency communications are not an
issue, then there is no reason to use TCONS.

Gregm