[CESG] Can we put a quick discussion of the SSI Architecture Document on the agenda for the telecon?

Tue Oct 8 08:05:13 EDT 2013

Chris,

With respect to the SSI Architecture Document

I'm just looking for a way to move the document forward.  We went through the whole process of pulling the document from CESG review so that it could be reviewed by the SISG (at your request, as I recall).  In the end I think that was a good move, as we ended up with a product that the 'customer' (since the SSI Architecture Document was in some sense commissioned by IOAG/SISG) was happy with.  After that process, which included many CESG members, we got a bunch of RIDs back against the document that would require, in my opinion, significant changes to the document.  Since this particular document was generated specifically at the request of the IOAG/SISG and since they pushed forward to get an IOP resolution based on the current draft, I'd like to be careful before we make wholesale changes and issue it.

To be clear, I don't think there's anything 'wrong' with Peter's desired reorganization of the document (roughly speaking, by 'degree of change to the current infrastructure' rather than the current organization 'by degree of inter-agency coordination needed/used').  At the same time, I think the current document organization also makes sense AND, I believe, is better aligned with the desires of the SISG since the main focus of the SISG/IOAG was on the inter-agency coordination needed to effect cross-supported networked operations.  The bulk of the technical content of the document would remain the same, it would just be organized differently with different emphasis.

Since many SISG participants are also on the CESG, and since this is at this point a CCSDS issue with what to do with the document, I'd like a quick discussion of peoples' positions.  If you think it's not worth rewriting the document at this point, I think that's worth noting.

About CFDP

I agree with you in principle that CFDP shouldn’t be crippled to advance networking, with the caveat that we should also not try to turn 'file transfer' into either a data link protocol (which is how I would see trying to do an end-to-end data transfer via multiple file transfers) or a pseudo-network protocol (which is what the current extended procedures and SFO do).  From nearly any metric (e.g. complexity, code footprint, reliability, cross-supportability) there's no detriment to the CFDP over network model with respect to current CFDP.  If missions really only care about the service (file transfer), we should be able to move to CFDP with a network underneath, making the flight software simpler, easier to write and maintain, and more robust while still keeping the missions happy.

Said differently, I'm all for CFDP and mission uptake of it, and would also be opposed to crippling it.  At the same time, I am opposed to CFDP trying to do things that a file transfer protocol really shouldn't do when we have a network protocol that can support it as well as other applications.  I'm not going to oppose maintaining those features in the CFDP spec that missions need in the near future, but long-term I think a model where CFDP is an application-layer (only) protocol over a network protocol is Better (tm).  We need to explain to missions that CFDP/BP really is 80% just a refactoring of functionality that the current CFDP already has (maybe more if we count SFO) that results in a much more capable, flexible, and cross-supportable system.

                        --keith

-----Original Message-----
From: Chris.Taylor at esa.int [mailto:Chris.Taylor at esa.int]
Sent: Tuesday, October 08, 2013 7:34 AM
To: Scott, Keith L.
Cc: CCSDS Engineering Steering Group - CESG Exec (cesg at mailman.ccsds.org); cesg-bounces at mailman.ccsds.org; John.j.rush at nasa.gov; Nestor Peccia (nestor.peccia at esa.int); Burleigh, Scott C (313B)
Subject: Re: [CESG] Can we put a quick discussion of the SSI Architecture Document on the agenda for the telecon?

Scott and all, I would like to add my pennyworth on the SSI document.

The document has been around for years now and I wonder if is really worth

trying to improve it any further when there are other issue to be solved.

CCSDS can push the SSI as much as they want but in the end the only way our

mission will take it onboard (unintended pun) is if they see a benefit,

mainly in terms of science return and potentially in reduced operations

costs.

On new ESA missions (Euclid and JUICE)  we are now seeing a move from the

conventional  packet store and TM dump towards an onboard filing system and

the transfer of files in foreword and return directions using CFDP. This is

clearly a big step forwards but is has taken a significant effort  to

convince our project people, supported by analysis, test-bedding and

tutorials. Even so,  there are still those who persist on maintaining the

status quo and indeed there are still some advantages to self -identifying,

self-contained packets, especially when operating over long delay links,

where retransmission becomes an difficult.

I know I have expressed this point before, but here it is again: the way

forward to DTN take up is to first to establish file based operations as the

way of doing business in our missions. To support this by promoting the use

of the existing  CFDP protocol  (including the currently planned updates) and

to ensure that the necessary ground x-support services are established (I

don't believe they are yet, especially when I see the proposed BOF on ground

based file transfer). Once we have the community using files and file

transfer as nominal way of operating, the shift to DTN an the SSI will make

far more sense and will meet less resistance. On no account should we try and

cripple the existing CFDP protocol in an attempt to make DTN more attractive.

Even with the use of conventional file transfer there are issues which must

be resolved:

- The interface between instruments and the onboard mass memory - typically

this is based on self identifying packets so that even if packets are lost

science can be returned (I know that this shouldn't happen with a reliable

transfer but things can go wrong). The question is if we don't use packets,

what formatting should we promote to our instrument providers?

- The need for quick look data to determine if bulk science data should be

downloaded or deleted (sometimes implemented by selecting individual packets

from a packet store) but if we use files, the quick look data needs to be in

a separate file, again a change to the instrument interface and to the

operational scenario.

- HK data for platform and payload is typically stored in packets in a packet

store, sometime the complete packet store is download but sometimes the

download is only performed if there has been an onboard anomaly. In this case

the packets for download are selected by time. ( with file based ops we can

only download the complete file.

- observation related  information is generally required to be downloaded to

enable the associated science data to be processed. Again typically in

individual packets with the packet header containing  timing and validity

information  which we do not have with files.

There are also questions to be answered in the ground segment -  where is the

CFDP engine located (in the ground station or control centre or both).

The above, among others are all questions posed by the Euclid and Juice

projects. As CCSDS, we also need to cover the aspect of interoperability,

particularly for the ground segment but in the longer term also the space

segment.

The point,  as I see it is that we have probably spent enough time on laying

out the ground work and road map for the SSI. What needs to be done now is to

ensure that the associated transfer protocols are complete and fit for

purpose and  ensure that we can meet the actual mission application related

requirements.

Regards,

//ct

From: "Scott, Keith L." <kscott at mitre.org<mailto:kscott at mitre.org>>

To:      "Nestor Peccia (nestor.peccia at esa.int<mailto:nestor.peccia at esa.int>)" <nestor.peccia at esa.int<mailto:nestor.peccia at esa.int>>,

Cc:      "Burleigh, Scott C \(313B\)" <scott.c.burleigh at jpl.nasa.gov<mailto:scott.c.burleigh at jpl.nasa.gov>>,

            "John.j.rush at nasa.gov<mailto:John.j.rush at nasa.gov>" <John.j.rush at nasa.gov<mailto:John.j.rush at nasa.gov>>, "CCSDS Engineering

            Steering Group - CESG Exec         \(cesg at mailman.ccsds.org\<mailto:cesg at mailman.ccsds.org\>)"

            <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>

Date:  07/10/2013 20:41

Subject:         [CESG] Can we put a quick discussion of the SSI Architecture

            Document on the agenda for the telecon?

Sent by:         cesg-bounces at mailman.ccsds.org<mailto:cesg-bounces at mailman.ccsds.org>

Nestor,

SIS and SEA are trying to resolve the RIDS against the SSI architecture

document from the SEA area.  Peter’s proposal is to redefine the ‘stages’ of

the SSI architecture document around ‘degree of change to existing networks’

rather than the current ‘degree of automation / cross-support’.  Resolving

the RIDs would result in (I believe) significant changes in the document with

respect to what was sent to and approved by SISG / IOP.  I’m concerned that

large changes to the document at this point could be disruptive.

Attached are the SEA RIDs and a document from Peter describing his proposed

changes.

I’d like to discuss with the CESG what our options are for moving forward:

      1)    Go with Peter’s proposal (change the document)

      2)    Reject Peter’s RIDs and publish the document as-is

      3)    Consult with the SISG to determine their opinion

      4)    Other?

   Best Regards,

                     --keith

Dr. Keith Scott

Office: +1.703.983.6547

Principal Engineer, E535

kscott at mitre.org<mailto:kscott at mitre.org>

The MITRE Corporation

M/S H300

7515 Colshire Drive

McLean, VA 22102

Area Director, CCSDS Space Internetworking Services

MITRE self-signs its own certificates.  Information about the MITRE PKI

Certificate Chain is available from http://www.mitre.org/tech/mii/pki/

    [attachment "730x1g01_CESG_Approval-SEA.pdf" deleted by Chris

   Taylor/estec/ESA] [attachment "IOP-3 SISG Updated proposal - 7Oct13.pptx"

   deleted by Chris Taylor/estec/ESA]

   _______________________________________________

   CESG mailing list

   CESG at mailman.ccsds.org<mailto:CESG at mailman.ccsds.org>

   http://mailman.ccsds.org/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20131008/68ae61b1/attachment-0001.html