<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Hi, all. It is of course way too late to seriously consider any change to the CFDP Revisions specification that we are about to interoperability-test. I offer the following comment only to make us all aware of the question in advance
of the testing, so that it doesn’t take us by surprise.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the course of helping the Europa Clipper project with requirements verification, I learned a little more about CRCs. In particular, it was noted that there may be a performance issue with the CRC-32 algorithm that will now be an optional
alternative to the modular checksum in CFDP; I dimly recall, in fact, that in our pre-interoperability testing it has already been revealed that CRC-32 verification of a multi-gigabyte file was quite time-consuming. (Sorry, I can’t just now find the email
that pointed this out.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ken Anderson, a coding expert at JPL, commented as follows:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><i>The computer science community has developed a set of algorithms with fairly similar properties, though intended to solve very different problems in efficient searches. Some of these are the Fletcher checksums,
particularly Fletcher-16 that produces a 16-bit value. It is a position-dependent checksum, and as Wikipedia says, its objective is “to provide error-detection properties approaching those of a cyclic redundancy check but with the lower computational effort
associated with summation techniques.” <o:p></o:p></i></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Depending on what we find during interoperability testing, we may want to consider a small interim update – replacing CRC-32 with something like a Fletcher checksum – some time after publication of the updated CFDP Blue Book.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Scott<o:p></o:p></p>
</div>
</body>
</html>