[Sis-csi] Green book thoughts

[Chris.Taylor at esa.int]

This is one of the more interesting discussions that has been generated by
group and there is another aspect related to retransmission that has not been
touched upon. From what I have seen over the years ( I work in the area of
flight system design), ground controllers are extremely careful and  hesitant
when it comes to releasing commands to the spacecraft. Automated sequences
are anathema and there is still a clear preference to release each command by
hand. I guess this practise is easily understood when it is considered that a
single incorrect command could result in the unrecoverable loss of  remote
hardware. Some may argue that this is even more reason for relying on
automated software but as this is also hand crafted and subject to bugs, I
believe the "man in the loop" aspect will remain important part of spacecraft
control.

This is backed up here by the slow take-up of CFDP. I still remember the
faces of horror when I made the original proposal for CFDP to our revered
CCSDS management council. The flight systems guys were in favour but the
support from the ground system institutions was miserable and it was treated
somewhat with disbelief that someone was suggesting automatic retransmission
to and from a spacecraft. So far we do not have a CFDP implementation on any
ESA spacecraft and even though the take up from NASA has been more positive,
I'm pretty sure that only the connectionless procedures have so far been
implemented.

It should also not be forgotten that CCSDS packet telecommand has supports
ARQ for  in the form of the COP procedures ( basically HDLC). Here ESA has
taken a lead and for years, due to a standard ASIC, all our spacecraft have
had the opportunity to use retransmission on the forward link. Two points are
however worthy of note: in a typical mission retransmission has not been
triggered; if it has been triggered there was significant effort to find out
why. In reality, this comes down to the links that are used. The forward link
is typically over-engineered to cover contingency situations (we also have
enough power on the ground to fry fish and clips onboard), and the return
links are so well coded that data loss hardly considered.

I guess one message from this is that we should be looking at the link
characteristics before deciding what is necessary higher up in the stack. If
our links are near on perfect occasional data loss due to link errors could
be acceptable and errorrs (e.g. due to SEUs in the flight system) can be
covered by application level checksum.

On the question of congestion, I still believe that the mission preplanning
will counteract the lack of overall bandwidth. The idea that data transfer
will not have a major element of preplanning doesn't make much sense if
crucial or mandatory data transmission is to be protected. Presumably
automated tools will be available to determine what each element needs to
transmit and in what time frame, so it should be easy enough to ensure that
the bandwidth is available when it is needed. It is also simple enough to
implement rate control for unbounded transfers such as file transfers. We are
already using this technique in the Columbus element of ISS where the
ethernet Lan is shared by several payloads and the Columbus system. We simply
slug the packet (UDP) release rate for each payload so that the maximum
allocated bandwidth is never exceeded. The release rate being configurable as
part of the mission timeline.

I guess, I come down of the side of Scott, do not jump to the conclusion that
TCP will be necessary. Take a better look at the link characteristic to
determine what recovery may be necessary ( I realise that space to space and
lander/rover related transmission may be more problematic) and assume that an
element of preplanning will cover that congestion issues.

//ct