[Sls-slp] FW: Comments on recent USLP drafts

[Kazz, Greg J (312B)]

Dear SLP WG,

We will discuss Marjorie¹s comments at our meeting on Monday at Caltech.

Safe Journey!

Greg
CCSDS SLP WG chairman

On 3/16/15, 6:34 AM, "Marjorie de Lande Long" <marjorie at delandelong.com>
wrote:

>Greg,
>
>I have had a look at the two latest draft documents for USLP and have a
>few comments.
>
>[Documents:
>- Unified Space Link Protocol (USLP), Draft Green Book,
>CCSDS 732.1-G-0.2, December 9, 2014
>(file 732x1-G-0 2_USLP_Green_Jan6_2015.doc)
>- Unified Space Link Protocol, Draft White Book,
>CCSDS 732.1-W-9, December 2014
>(file 732x1w09.1_USLP_White_Jan6_2015.doc)]
>
>1. Relationship to COP-1/P
>
>The Draft Green Book, section 2.1.2.13, says 'We envision USLP being
>backward compatible with COP-1/P'.
>
>The Draft White Book, Annex F, section F1, says 'The USLP frame can be
>structured to resemble the Telecommand frame' and then describes using
>the VC sequence counter for a Go-Back-N protocol.
>
>However, the USLP defined in the Draft White Book does not appear to
>support the inclusion of a retransmission mechanism such as COP-1 or
>COP-P within a USLP protocol entity.  For example:
>- section 2.4.1 says that the USLP protocol does not perform
>retransmission of protocol data units, and
>- the COP-1 Management Service is not supported.
>
>Therefore, I think the compatibility with COP-1/P mentioned in the Draft
>Green Book needs some clarification.
>
>2. Flexible frame format to support future needs
>
>The design of the USLP frame format is intended to be flexible, with
>support for future needs, but I think this flexibility could be
>improved.  Here are a few considerations.
>
>2.1 Support for spacecraft addressing
>
>The only support for spacecraft addressing provided in the header of the
>USLP Transfer Frame is a single Spacecraft Identifier field with a
>single flag that indicates source or destination.
>
>For example, this does not support scenarios that prefer to have both
>source and destination Spacecraft Identifiers. (This is mentioned in the
>slide 'Possible Modifications to USLP' in the presentation 'Why we need
>USLP' from last November.)
>
>The Spacecraft Identifier may be used as a kind of network address:
>section 3.4 of the Draft Green Book discusses the use of USLP frames in
>a frame relay service.  In the current design of the USLP frame format
>the Spacecraft Identifier field supports up to 8192 Spacecraft
>Identifiers, and the design provides no mechanism for increasing the
>size of the field - this is a lot of spacecraft, but network addressing
>fields are famous for running out of bits.
>
>2.2 Longer fields
>
>Some fields in the USLP frame could just be defined with a longer
>length.
>
>While it is good to keep down the overheads of the fixed parts of a
>frame header, these overheads are relatively smaller when the frames are
>longer.  By being too "economical" with the bits in the header, there
>may be less flexibility available in the future.
>
>Just as an example (not a proposal for a specific change!), with the
>addition of one extra octet to the USLP Transfer Frame Header, the eight
>extra bits could be used to:
>- Increase the length of the Spacecraft Identifier field from 13 to 16
>bits.
>- Replace the 1-bit OCF Flag with a 3-bit field that supports other
>sizes of OCF than the current 4 octets. (The 4-octet OCF was designed
>for use with COP-1. An optionally larger OCF might be welcome for SDLS.)
>- Provide three additional reserved bits (or flags) to allow for future
>SLP needs.
>
>Another example is the Insert Zone, which is defined as having a 1-octet
>length field as its first octet (4.1.4. in the Draft White Book).  There
>might be future applications for the Insert Zone that need to have more
>than 255 octets of insert data in a frame, so maybe the length field
>could be longer than 1 octet?  A 12-bit length field would allow an
>Insert Zone up to 4K octets.
>
>2.3 Support for the fields that no-one has thought of yet
>
>Provision for new fields could be supported by including some additional
>reserved bits in the frame header, which could be used later to signal
>the presence of new fields.
>
>3. Very high rate links
>
>Section 2.1.2.7 of the Draft Green Book discusses some very high rate
>links with rates exceeding 1 Gbit/sec.  It mentions a 30 Gbit/sec link,
>which could transfer 2,343,750 frames per second with a frame size of
>16,000 octets.
>
>The longer frame lengths supported by USLP make it possible to greatly
>reduce the frame rate on such links, compared to TM or AOS.  But even
>with USLP, a system designed to receive and process such a link might
>need to split the processing, perhaps across multiple parallel
>processors, or perhaps by directing some frames to storage for off-line
>processing.  In any case, the presence of variable-length frames on the
>link could add to the complexity of planning for a smooth and balanced
>handling of the frames.
>
>Does the USLP design include any other features to support these links?
>Would USLP include Application Profiles to limit the use of
>variable-length frames on very high rate links such as 30 Gbit/sec?
>
>4. Variable length frames, unaligned with the code blocks
>
>Perhaps my questions here should be addressed to SLS-C&S rather than
>SLS-SLP.
>
>The proposed method in USLP for handling of variable length transfer
>frames with a fixed length block code is similar to the method used by
>Proximity-1.  Proximity-1 frames have a maximum length of 2048 octets
>and use an LDPC code with an input block length of 128 octets(?).  So a
>maximum length frame can be sliced across 17 codeblocks.
>
>How well does this work with a very big frame, such as 60,000
>octets? Presumably a longer code could be used with USLP, such as
>892-octet LDPC?  - which would slice a 60,000 octet frame across 68
>code blocks. Has this been tested at this sort of scale?
>
>Best regards,
>Marjorie
>
>
>Marjorie de Lande Long
>I B + M A de Lande Long
>Software + Consultancy
>marjorie at delandelong.com
>
>