[Css-csts] FW: Ambiguous specification of CLTU transfer buffer behavior

[John Pietras]

Wolfgang,
Thanks of the quick response. As you can see, I'm adding Jeff Boxell,
who raised this issue, to the distribution list. 

Jeff, has this difference caused any operational problems, or is it just
a matter of looking for consistency in implementation and interpretation
of the buffer level that's being reported back? 

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970

> -----Original Message-----
> From: Wolfgang.Hell at esa.int [mailto:Wolfgang.Hell at esa.int]
> Sent: Monday, June 02, 2008 3:43 AM
> To: John Pietras
> Cc: css-csts at mailman.ccsds.org; css-csts-bounces at mailman.ccsds.org
> Subject: Re: [Css-csts] FW: Ambiguous specification of CLTU transfer
> buffer behavior
> 
> 
> John,
> 
> Firstly you are correct that the F-CLTU specification does not
prescribe
> any
> specific implementation of the interface between the CLTU buffer and
the
> modulator. In practice, in particular if also higher command rates
shall
> be
> reported, I would assume that most implementations will feature a
double
> buffer as to make sure that radiation of consecutive CLTUs can be
> contiguous
> without idle sequence in between except where that is imposed by the
> delay-time specified by the service user.
> 
> The real-world implementations that I have seen so far all provided
ample
> buffering so that parameter cltu-buffer-available is of hardly any
> interest
> from an operational perspective as it won't be filled up anyway in any
> realistic scenario.
> 
> Besides that I feel that the specification is not ambiguous in the
sense
> that
> the provider is supposed to report the available buffer at the point
in
> time
> when the CLTU-TRANSFER-DATA response is generated. I concede that
because
> of
> the unspecified input buffer to the modulator two different
> implementations
> with the same buffer capacity under the same operational condition may
> report
> different values for the available buffer capacity. I do not regard
that
> to
> be a problem.
> 
> The above is my personal view on this issue and other members of the
WG
> may
> have a different view. If so, I would appreciate to get such input as
soon
> as
> possible so that I can take that into account before sending the
updated
> CLTU
> spec to the CCSDS secretariat.
> 
> Best regards,
> 
> Wolfgang
> 
> 
> 
> 
> 
>              "John Pietras"
>              <john.pietras at gst.
>              com>
> To
>              Sent by:                   <css-csts at mailman.ccsds.org>
>              css-csts-bounces at m
> cc
>              ailman.ccsds.org
> 
> Subject
>                                         [Css-csts] FW: Ambiguous
>              30/05/2008 18:41           specification of CLTU transfer
>                                         buffer      behavior
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Members of the CSTSWG:
> 
> The following email exchange describes an ambiguity encountered in the
> defined behavior of the CLTU buffer in the FCLTU specification. If you
> have
> an interest in this issue, please comment on whether the behavior of
the
> CLTU
> buffer should be more tightly defined in the FCLTU specification.
> 
> Best regards,
> John
> 
> From: John Pietras
> Sent: Friday, May 30, 2008 12:33 PM
> To: 'Boxell, Jeff'; css-csts at mailman.ccsds.org
> Cc: Michael Stoloff; Kazz, Greg J (X-JPL); Peter Shames; Erik Barkley;
> Fred
> Brosi; Petkevich, Michael; Kluksdahl, Norman C. (JSC-DD22); Hill,
Frank9
> Subject: Ambiguous specification of CLTU transfer buffer behavior
> 
> Jeff,
> It's possible that the ambiguity that you have encountered was
> intentionally
> left "loose" to accommodate some flexibility in vendor implementations
and
> user requirements, but I am not certain of that. I'll forward the
> pertinent
> part of your note to the membership of the Cross Support Transfer
Service
> Working Group, which is responsible for maintaining the SLE
> specifications.
> 
> Best regards,
> John
> 
> 
> From: Boxell, Jeff [mailto:jeff.boxell at lmco.com]
> Sent: Friday, May 23, 2008 11:55 AM
> ..
> Subject: RE: SLE provider
> 
> ... I would like to get your thoughts on a possible upgrade to the SLE
Spec
> based the difficulties we experienced having 1 SLE User implementation
> talk
> to two different vendor SLE provider implementations (one vendor user
for
> real-time operations, another used strictly for simulations).  Each
vendor
> managed the reporting of the CLTU buffer level differently.  One
vendor
> extracted a CLTU to be radiated and immediately started radiating the
> CLTU;
> the other vendor extracted a CLTU and staged it for radiation so that
2
> CLTUs
> were typically outside the CLTU buffer (one being radiated, the other
> waiting
> to be radiated).   To keep our buffer level management and reporting
in
> sync,
> we asked the SIM vendor to tailor their implementation to meet the
other's
> implementation and they willingly did this.  Together we looked at the
> Specs
> and saw that this level of detail was not explicitly specified.  Can
you
> give
> me some feedback on what might be done to prevent others from
encountering
> this problem (e.g. should I submit an update to the Spec)?
> ...
> 
> Jeff Boxell
> Lockheed Martin Mission Services
> Houston, Tx
> 281-853-2240_______________________________________________
> Css-csts mailing list
> Css-csts at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts