<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 20px; font-family: Calibri, sans-serif;">
<div>Dear SLP WG,</div>
<div>Preliminary responses back on Marjorie’s comments. Please see below.</div>
<div>For discussion at the SLP meeting at Monday’s meeting.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Greg</div>
<div>Chairman CCSDS SLP WG</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><Greenberg>, "Edward (312B)" <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Date: </span>Monday, March 16, 2015 at 8:40 PM<br>
<span style="font-weight:bold">To: </span>Marjorie de Lande Long <<a href="mailto:marjorie@delandelong.com">marjorie@delandelong.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:Stefan.Veit@dlr.de">Stefan.Veit@dlr.de</a>" <<a href="mailto:Stefan.Veit@dlr.de">Stefan.Veit@dlr.de</a>>, Cosby Matthew <<a href="mailto:MCOSBY@qinetiq.com">MCOSBY@qinetiq.com</a>>, "Kazz, Greg J (313B)"
<<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Subject: </span>RE: Comments on recent USLP drafts<br>
</div>
<div><br>
</div>
<div 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">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.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]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On 3/16/15, 6:34 AM, "Marjorie de Lande Long" <<a href="mailto:marjorie@delandelong.com"><span style="color:windowtext;text-decoration:none">marjorie@delandelong.com</span></a>><o:p></o:p></p>
<p class="MsoPlainText">wrote:<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>[Documents:<o:p></o:p></p>
<p class="MsoPlainText">>- Unified Space Link Protocol (USLP), Draft Green Book, CCSDS
<o:p></o:p></p>
<p class="MsoPlainText">>732.1-G-0.2, December 9, 2014 (file 732x1-G-0 <o:p></o:p></p>
<p class="MsoPlainText">>2_USLP_Green_Jan6_2015.doc)<o:p></o:p></p>
<p class="MsoPlainText">>- Unified Space Link Protocol, Draft White Book, CCSDS 732.1-W-9,
<o:p></o:p></p>
<p class="MsoPlainText">>December 2014 (file 732x1w09.1_USLP_White_Jan6_2015.doc)]<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>1. Relationship to COP-1/P<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>The Draft Green Book, section 2.1.2.13, says 'We envision USLP being
<o:p></o:p></p>
<p class="MsoPlainText">>backward compatible with COP-1/P'.<o:p></o:p></p>
<p class="MsoPlainText"><span style="color:red">The Green book provides a view of the total protocol which includes the COP. Some insist that the COP is a transport function that utilizes the services provided by the link layer. In addition, the Green book
hints about using the insert zone for many things including carrying a sender’s SCID.</span><o:p></o:p></p>
<p class="MsoPlainText">>The Draft White Book, Annex F, section F1, says 'The USLP frame can be
<o:p></o:p></p>
<p class="MsoPlainText">>structured to resemble the Telecommand frame' and then describes using
<o:p></o:p></p>
<p class="MsoPlainText">>the VC sequence counter for a Go-Back-N protocol.<o:p></o:p></p>
<p class="MsoPlainText">><span style="color:red">At this time the White Book does not include the COP or the Protocol for PROX for any supervisory commands. The format described in the White book provides a CLTW service that can support the COP as well as
Security reporting. It describes how to do segmentation and the use of “MAPs” for internal routing. But we have just started and getting the data Protocol on the table is the first step. The next step would be to introduce the State Tables and operations
for COP , Prox and TC. <o:p></o:p></span></p>
<p class="MsoPlainText">>However, the USLP defined in the Draft White Book does not appear to
<o:p></o:p></p>
<p class="MsoPlainText">>support the inclusion of a retransmission mechanism such as COP-1 or
<o:p></o:p></p>
<p class="MsoPlainText">>COP-P within a USLP protocol entity. For example:<o:p></o:p></p>
<p class="MsoPlainText">>- section 2.4.1 says that the USLP protocol does not perform
<o:p></o:p></p>
<p class="MsoPlainText">>retransmission of protocol data units, and<o:p></o:p></p>
<p class="MsoPlainText">>- the COP-1 Management Service is not supported.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Therefore, I think the compatibility with COP-1/P mentioned in the
<o:p></o:p></p>
<p class="MsoPlainText">>Draft Green Book needs some clarification.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>2. Flexible frame format to support future needs<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>The design of the USLP frame format is intended to be flexible, with
<o:p></o:p></p>
<p class="MsoPlainText">>support for future needs, but I think this flexibility could be
<o:p></o:p></p>
<p class="MsoPlainText">>improved. Here are a few considerations.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>2.1 Support for spacecraft addressing<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>The only support for spacecraft addressing provided in the header of
<o:p></o:p></p>
<p class="MsoPlainText">>the USLP Transfer Frame is a single Spacecraft Identifier field with a
<o:p></o:p></p>
<p class="MsoPlainText">>single flag that indicates source or destination. <span style="color:red">
The Insert zone can be the carrier of the missing data. This was intentional because adding the second address in every frame is overkill and this is a link protocol not a network protocol. We did however consider that a relay could be used as a truck carrier
for relaying a link data unit. </span><o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>For example, this does not support scenarios that prefer to have both
<o:p></o:p></p>
<p class="MsoPlainText">>source and destination Spacecraft Identifiers. (This is mentioned in
<o:p></o:p></p>
<p class="MsoPlainText">>the slide 'Possible Modifications to USLP' in the presentation 'Why we
<o:p></o:p></p>
<p class="MsoPlainText">>need USLP' from last November.)<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>The Spacecraft Identifier may be used as a kind of network address:<o:p></o:p></p>
<p class="MsoPlainText">>section 3.4 of the Draft Green Book discusses the use of USLP frames in
<o:p></o:p></p>
<p class="MsoPlainText">>a frame relay service. In the current design of the USLP frame format
<o:p></o:p></p>
<p class="MsoPlainText">>the Spacecraft Identifier field supports up to 8192 Spacecraft
<o:p></o:p></p>
<p class="MsoPlainText">>Identifiers, and the design provides no mechanism for increasing the
<o:p></o:p></p>
<p class="MsoPlainText">>size of the field - this is a lot of spacecraft, but network addressing
<o:p></o:p></p>
<p class="MsoPlainText">>fields are famous for running out of bits.<o:p></o:p></p>
<p class="MsoPlainText"><span style="color:red">We have been asked by some commenters to increase the SCID field. It is easy right now to add a single bit and double the number of SCIDs available.<o:p></o:p></span></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>2.2 Longer fields<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Some fields in the USLP frame could just be defined with a longer
<o:p></o:p></p>
<p class="MsoPlainText">>length.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>While it is good to keep down the overheads of the fixed parts of a
<o:p></o:p></p>
<p class="MsoPlainText">>frame header, these overheads are relatively smaller when the frames
<o:p></o:p></p>
<p class="MsoPlainText">>are longer. By being too "economical" with the bits in the header,
<o:p></o:p></p>
<p class="MsoPlainText">>there may be less flexibility available in the future.
<span style="color:red">We can envision longer frames but there needs to be a balance and that is where economy is important.<o:p></o:p></span></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Just as an example (not a proposal for a specific change!), with the
<o:p></o:p></p>
<p class="MsoPlainText">>addition of one extra octet to the USLP Transfer Frame Header, the
<o:p></o:p></p>
<p class="MsoPlainText">>eight extra bits could be used to:<o:p></o:p></p>
<p class="MsoPlainText">>- Increase the length of the Spacecraft Identifier field from 13 to 16
<o:p></o:p></p>
<p class="MsoPlainText">>bits. <span style="color:red">You are correct and we have no problem accepting that. We have been hammered by the fault tolerant enthusiasts to keep the frame size as small as possible for emergency ops. Personally we believe that
the improved uplink coding gain obviates that requirement by proving higher data rates.
</span><o:p></o:p></p>
<p class="MsoPlainText">>- Replace the 1-bit OCF Flag with a 3-bit field that supports other
<o:p></o:p></p>
<p class="MsoPlainText">>sizes of OCF than the current 4 octets. (The 4-octet OCF was designed
<o:p></o:p></p>
<p class="MsoPlainText">>for use with COP-1. An optionally larger OCF might be welcome for
<o:p></o:p></p>
<p class="MsoPlainText">>SDLS.) <span style="color:red">A reasonable proposal, but again this can be handled in an insert zone.</span><o:p></o:p></p>
<p class="MsoPlainText">>- Provide three additional reserved bits (or flags) to allow for future
<o:p></o:p></p>
<p class="MsoPlainText">>SLP needs.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Another example is the Insert Zone, which is defined as having a
<o:p></o:p></p>
<p class="MsoPlainText">>1-octet length field as its first octet (4.1.4. in the Draft White
<o:p></o:p></p>
<p class="MsoPlainText">>Book). There might be future applications for the Insert Zone that
<o:p></o:p></p>
<p class="MsoPlainText">>need to have more than 255 octets of insert data in a frame, so maybe
<o:p></o:p></p>
<p class="MsoPlainText">>the length field could be longer than 1 octet? A 12-bit length field
<o:p></o:p></p>
<p class="MsoPlainText">>would allow an Insert Zone up to 4K octets. <span style="color:red">
On this we disagree. If you need more that 255 bytes create a new frame.</span><o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>2.3 Support for the fields that no-one has thought of yet<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Provision for new fields could be supported by including some
<o:p></o:p></p>
<p class="MsoPlainText">>additional reserved bits in the frame header, which could be used later
<o:p></o:p></p>
<p class="MsoPlainText">>to signal the presence of new fields. <span style="color:red">
Sure</span><o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>3. Very high rate links<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Section 2.1.2.7 of the Draft Green Book discusses some very high rate
<o:p></o:p></p>
<p class="MsoPlainText">>links with rates exceeding 1 Gbit/sec. It mentions a 30 Gbit/sec link,
<o:p></o:p></p>
<p class="MsoPlainText">>which could transfer 2,343,750 frames per second with a frame size of<o:p></o:p></p>
<p class="MsoPlainText">>16,000 octets.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>The longer frame lengths supported by USLP make it possible to greatly
<o:p></o:p></p>
<p class="MsoPlainText">>reduce the frame rate on such links, compared to TM or AOS. But even
<o:p></o:p></p>
<p class="MsoPlainText">>with USLP, a system designed to receive and process such a link might
<o:p></o:p></p>
<p class="MsoPlainText">>need to split the processing, perhaps across multiple parallel
<o:p></o:p></p>
<p class="MsoPlainText">>processors, or perhaps by directing some frames to storage for off-line
<o:p></o:p></p>
<p class="MsoPlainText">>processing. In any case, the presence of variable-length frames on the
<o:p></o:p></p>
<p class="MsoPlainText">>link could add to the complexity of planning for a smooth and balanced
<o:p></o:p></p>
<p class="MsoPlainText">>handling of the frames. <span style="color:red">True, but there is no requirement that a link management agreement can’t include fixed length frames. I envision fixed length TFDFs to more efficiently use mass store.
</span><o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Does the USLP design include any other features to support these links?<o:p></o:p></p>
<p class="MsoPlainText">>Would USLP include Application Profiles to limit the use of
<o:p></o:p></p>
<p class="MsoPlainText">>variable-length frames on very high rate links such as 30 Gbit/sec?<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>4. Variable length frames, unaligned with the code blocks<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Perhaps my questions here should be addressed to SLS-C&S rather than
<o:p></o:p></p>
<p class="MsoPlainText">>SLS-SLP.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>The proposed method in USLP for handling of variable length transfer
<o:p></o:p></p>
<p class="MsoPlainText">>frames with a fixed length block code is similar to the method used by
<o:p></o:p></p>
<p class="MsoPlainText">>Proximity-1. Proximity-1 frames have a maximum length of 2048 octets
<o:p></o:p></p>
<p class="MsoPlainText">>and use an LDPC code with an input block length of 128 octets(?). So a
<o:p></o:p></p>
<p class="MsoPlainText">>maximum length frame can be sliced across 17 codeblocks.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>How well does this work with a very big frame, such as 60,000 octets?
<o:p></o:p></p>
<p class="MsoPlainText">>Presumably a longer code could be used with USLP, such as 892-octet
<o:p></o:p></p>
<p class="MsoPlainText">>LDPC? - which would slice a 60,000 octet frame across 68 code blocks.
<o:p></o:p></p>
<p class="MsoPlainText">>Has this been tested at this sort of scale? <span style="color:red">
We know that the LDPC codes have no error floor. Thus the code word error rates can be expected to approach zero if a high enough SNR is provided. We have set the maximum frame size as 65k bytes but would 32k bytes be more reasonable?</span><o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Best regards,<o:p></o:p></p>
<p class="MsoPlainText">>Marjorie<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">>Marjorie de Lande Long<o:p></o:p></p>
<p class="MsoPlainText">>I B + M A de Lande Long<o:p></o:p></p>
<p class="MsoPlainText">>Software + Consultancy<o:p></o:p></p>
<p class="MsoPlainText">><a href="mailto:marjorie@delandelong.com"><span style="color:windowtext;text-decoration:none">marjorie@delandelong.com</span></a><o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
</div>
</div>
</div>
</span>
</body>
</html>