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

[gregory.menke at gsfc.nasa.gov]

Keith Scott writes:
 > Comments inline.  Essentially: Why can't OBL support TCONS scheduled service
 > while allowing IP access to the 'non-scheduled' pieces of the link?  This
 > would seem to go a long way to allowing something like Max's picture.

Because the OBL only provides a uniform interface it disparate
datalinks.  It doesn't implement the bus schedules or other qos
features- that stuff is done in TCONS.


 
 > >
 > >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.
 > 
 > And precluding it from offering any service that can't be met with arbitrary
 > delays and jitter (the minimum characteristics the best effort service
 > defines).

If the protocol offers better realtime characteristics than TCONS,
then it should be used instead of TCONS- but, it will also have to
handle network and heterogenous datalinks.  This is the exact same
reason why app-layer protocols are generally put on top of UDP instead
of onto the IP layer or raw packets.


 > >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.
 > 
 > OBL can do the arbitration, right?  OBL should, I think, know darned well
 > what the protocol asking for services is (OBL has a next protocol
 > identifier, right?  Or does OBL only support TCONS network service?)  If OBL
 > only supports TCONS networking, then what we have is a completely stovepipe
 > network stack to meet the realtime requirements of TCONS.  That's good from
 > a performance standpoint, but if our answer is that in order to get the
 > realtime scheduled service the spacecraft designer has to buy OBL and all of
 > TCONS, and is then prevented from using any other network technology for
 > non-realtime traffic, I think we've lost.
 > 
 > There was conceptual agreement at the SIS/SOIS plenary in Montreal (Dai's
 > slide) of allowing TCONS to coexist side-by-side with something like IP.
 > This would put the burden on OBL to schedule the realtime traffic while at
 > the same time providing access to the non-scheduled parts of the link to
 > other network technologies (like IP).  This was deemed perferable to forcing
 > IP to run over TCONS (scheduled) service, which would seem the other option.

OBL only knows how to transmit and receive packets and translate
between abstract host addresses and datalink addresses.  Non-realtime
traffic is sent and received by interfacing to the TCONS api- its the
only way the network schedules and qos can be guaranteed.  TCONS knows
the schedules and is perfectly happy to clock out non-realtime traffic
when scheduled traffic is not being sent.

One big reason for not interfacing to the OBL is the OBL does not
include the network layer, so any stack interfaced in that way will
have to deal with address resolution and network addressing for all
the involved datalinks.  So the reasonable choice would be to
interface with the TCONS network layer.  But once you're there, you've
already bought the addressing model and the network pdu header, but
you still have to deal with application multiplexing and not screwing
up schedule traffic.  So at that point, since those issues are
presumably not germane to what the user's test protocol is supposed to
solve, then its easier to just interface to the best effort service
and move forward.  Presumably, the user's test protocol is
implementing some desirable solution to packet loss- otherwise why
bother- so putting it on top of the best effort allows it to operate
without disrupting ambient schedule traffic, its also able to take
advantage of the TCONS app multiplexing, address resolution and
network addressing- which it would otherwise have to deal with itself.

Gregm