[Css-csts] ESA Comments to JPL Paper "Generic SLE Data Transfer Service"

[Yves.Doat at esa.int]

Dear Charles,

Thank you very much for your presentation. We had a look to it and you will
find below some points complementing / commenting your paper.

---
Slide 2:
   Statement: The Tool-Kit should be specified without impacting the new
   services.
   In theory we fully agree with your statement. Unfortunately during our
   analysis we came to the conclusion that we should minimize the impact on
   the existing services. Some of the limitations imposed by the current
   definition may be incompatible with the new approach. In particular the
   definition of service specific parameters may imply an incompatibility
   with the existing SLE services. If we really wanted to exclude any impact
   on the existing services, then we would constrain ourselves to what is
   depicted as approach A on slide 7. In addition, the toolkit layer would be
   rather thin and therefore complexity in terms of specification in
   implementations would not be significantly reduced.
   It must however be noted that the WG does not intend to invalidate the
   existing service by defining the toolkit. The current services will remain
   as they are and at a later stage (depending on budget and requirements),
   one may consider a migration of the existing services to the toolkit
   approach.

   Statement: Explicitly define state tables for new services.
   Our understanding is that to the maximum possible extent we will try to
   come up with one generic state machine that is suitable for all new
   services that shall be developed. We concede a given service is likely to
   use only a subset of the generic state machine. The definition of that
   subset might be regarded a specific state machine for each service, but
   the reduction in terms of specification and implementation complexity
   should be obvious. Based on the findings obtained so far, we expect that
   we'll have to have different state tables for return services and  forward
   services, respectively. What for sure will remain service specific and
   needs to be specified very carefully is the semantic of the various
   parameters.

---
Slide 3: Possible Service Types
   Stream Transfer. During our last meeting in Toulouse, all participants
   from the area agreed to rename the RAD into RUFT (Return Unframed
   Telemetry)

   Our impression is that this slide does not address service types, but
   rather classifies the transport mechanism, which may be streaming, message
   passing, or file transfer. It may well be that a given service (or service
   type) supports more than one of these transport paradigms. For instance,
   the offline delivery mode of the return services could invoke a file
   transfer rather than invoking a series of TRANSFER-DATA operations.
   Similarly, the transfer of a file containing the CLTUs to be radiated
   could be integral part of an extended CLTU service.   File transfer
   service covers off-line data transfer which is a mode of the existing
   services and not a service in itself.

   For real-time delivery of radio-metric observables, we are not clear why
   this would fall into the stream transfer category rather than message
   transfer. As slides 7 and 8 show TCP as the only underlying transport
   mechanism, we are wondering what in practice the implications of a stream
   transfer as opposed to a message transfer would be. Is there any problem
   with delivering RUFT and/or Bit Stream (which probably can be merged to a
   common service) using essentially the existing return service protocol
   engine?

   Off-line return is covered in the current services as a delivery mode
   inside the existing return services.
   To be in line with the existing services, the radio-metric products should
   have three delivery modes: on-line complete, on-line timely and off-line
   delivery modes. The current services do not handle off-line delivery based
   on file transfer and this would be a change compared to the existing
   services.

   Catalog of data should be further described. In my opinion a catalog of
   data would be the result of a specific request from the user (e.g. the
   user requests the data for a precise time interval) and as such could be
   handled by an on-line delivery mode. We expect that the user in essence
   wants to browse / navigate in real time in a directory structure. Your
   catalog of data needs to be further clarified.

   We are not sure how CFDP fits in here. Do you propose to consider CFDP as
   file transfer protocol between ground segment entities? Do you propose to
   not terminate CFDP in the complex but rather in the control centre and you
   therefore see a need for a mechanism to 'extend' CFDP from the space link
   termination point to the control centre? Or do you intend to terminate
   CFDP in the complex, but want to specify a mechanism to move these files
   on ground?

   Message Transfer:
   We are not sure how interpret MIME/XML/HTTP. While MIME and XML can be
   regarded as transfer syntax specifications, HTTP is a protocol. Did you
   mean HTML?

---
Slide 4: Proposed new JPL required services
This slide clearly identifies new services. It would be very interesting to
identify which new service would make use of which new service type you
proposed in the previous slide.

---
Slide 5: Concerns regarding new services
   1st bullet: This is in line with all paper presented and discussed so far.

   2nd bullet: We have to identify those operations that would be most
   suitable for this new service. JPL could possibly propose a mapping with
   the existing ESA TN and White Book.

   3rd bullet: Could you please clarify how is MIME to be understood:
   'true-MIME' or 'MIME-like' approach?

   4th bullet. New bit stream service: The CCSDS community did not regard
   this service as a priority work item. JPL should perform the required
   analysis to make sure that the toolkit will offer all elements required to
   specify it..

   5th bullet. The use of FTP for file transfer is not against the discussion
   we had so far. A combination FTP plus on-line SLE service should be
   addressed.

   6th bullet. The need for MIME technology should be clarified.

---
Slide 6: Approaches
Approach A is in line with JAXA, ESA and CNES view of the SLE evolution.
Approach B looks to be an attempt to build on top of the toolkit a mechanism
for a "generic" return approach. Approach B looks not to be in contradiction
with Approach A. In fact, for some of the new services it may well be
possible that the toolkit provides all we need. But in that case, we would
not present it a shown on the slide. Rather, the SLE Generic Service Spec
layer would be empty, as the needs are fully covered by the toolkit. JPL
should further investigate this idea based on the existing document.
Approach C should be considered as a complementary approach to the other
approaches and not as a dedicated approach. One could think of a service
combining the Toolkit services with an FTP service. The file format (syntax
and semantic should be specified as part of the service itself. We am not
sure to see what HTTP would bring as an alternative.

Last slide:
JPL recommends to further investigate the proposed approaches. Considering
that JAXA and ESA are already focusing on the toolkit approach, it looks very
constructive to have JPL looking into the definition of the toolkit usage for
the future services.

As regards 'control' functions, there will be difficulties in getting these
accepted as a cross support element. Nonetheless, we should look into this
matter, since even if such function is used only within the realm of a given
agency, it is still beneficial if that function can be built on top of a well
proven infrastructure.

Best regards.

Yves Doat & Wolfgang Hell
ESA