[Sois-tcoa] [Sois-tcons] RE: reference model (2 levels
ofSOIS-compliance)
Keith Scott
kscott at mitre.org
Tue Mar 8 11:54:33 EST 2005
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.
--keith
>-----Original Message-----
>From: sois-tcons-bounces at mailman.ccsds.org
>[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of
>gregory.menke at gsfc.nasa.gov
>Sent: Thursday, March 03, 2005 3:55 PM
>To: Abhijit Sengupta
>Cc: sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
>Subject: Re: [Sois-tcoa] [Sois-tcons] RE: reference model (2
>levels ofSOIS-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.
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).
>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.
>
>
> >
> > > > 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
>
More information about the Sois-tcons
mailing list