[Sis-csi] Green book thoughts

[Scott Burleigh]

Chris.Taylor at esa.int wrote:

>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.
>
You are certainly right, Chris, but I would suggest that this is 
something of an artifact of history.  In the past, the only bits we ever 
sent to spacecraft were commands, so it was true that any uplink had the 
potential to crash the spacecraft.  Automated retransmission protocols 
are different: positive and negative acknowledgements are not commands 
and (unless your protocol implementation is inexcusably poorly written 
and tested) they won't ever crash a spacecraft.

>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.
>  
>
There is a persistent fallacy here, I think.  There are clearly critical 
spacecraft operational decisions that should only be made by humans 
exercising informed judgement.  There are, just as clearly, routine 
operational decisions that have got to be made by on-board software, 
either because the control loop through a human would be too long to 
enable timely response or because there are just too many of them to 
make manually in a cost-effective way.  The latter require that software 
be written and tested with great care, but however well that work is 
done you are going to rely on it; you've got no real choice.  If there 
are bugs, you fix them and *re-use the corrected software in the next 
mission instead of starting over again so that new bugs can be 
invented*.  But bugs in software, once soundly corrected, can never 
recur.  Human errors shouldn't, but always can and sometimes do.

>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.
>  
>
Not true, actually.  The acknowledged procedures of CFDP were routinely 
used for command sequence upload to the Deep Impact spacecraft and are 
used every day for engineering telemetry download from MESSENGER.  
What's more, the CFDP acknowledgements sent from the ground system to 
the MESSENGER spacecraft are issued automatically, without operator 
intervention, just as intended in the CFDP design.

>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.
>  
>
Sure.  Or techniques like erasure coding can even recover lost or 
corrupted data without retransmission, if there's not too much loss.

>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.
>  
>
Right, you've got to have rate control, and contacts are going to be 
scheduled (possibly automatically) for a number of reasons.  But I would 
say that congestion control in this context is more a question of buffer 
overrun (resulting in data loss) rather than lack of bandwidth, and in a 
truly networked communication environment you do have to worry about 
that at routers.  Sure, we're not facing any problem remotely like this 
at the moment.  But in a denser and more richly interconnected cislunar 
network environment I believe it will matter.

We don't have to predict the future accurately right now in order to 
settle the main question, though.  I think we just want to say that we 
know UDP support will be necessary, we think it's possible that support 
for TCP will be necessary in some contexts, we agree that other non-TCP 
mechanisms for assuring data transmission completeness may be necessary 
as well, but we agree that heedless proliferation of those mechanisms 
would impose undesirable costs on the space flight community.

Scott