<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [CESG] Draft Green Book on Space Packet
Protocol</title></head><body>
<div>Dear Takahiro,</div>
<div><br></div>
<div>I have read through your draft Green Book on the SPP (SPP-GB) and
find it to be a quite clear and easily understood presentation of the
concepts and use of the Space Packet Protocol (SPP). You have
done a really good job of presenting the materials in an accessible
form. There are a number of minor formatting and English usage
issues that surfaced, but these are more editorial than anything
else. I have an obvious bias, but I think that the use of the
RASDS diagram approach helps with the presentation of the concepts.
It will be interesting to hear how this is perceived by others.</div>
<div><br></div>
<div>I have also now read the revised SPP Red Book (SPP-RB) and there
are a few items in both documents that warrant further
discussion.</div>
<div><br></div>
<div><u>Space Packet Protocol</u></div>
<div><br></div>
<div>The most fundamental question for me is "Is there really a
Space Packet Protocol" or is there just a Space Packet
Construction Rule and a set of loosely defined processes that describe
things you might do with it? In SPP-RB all that is really
clearly defined are the packet construction rules. In this document
there are some functional / protocol views that describe how you might
construct entities that participate in the transfer of these packets,
and there is an abstract description of protocol entities, but these
is no solid definition of the state machines that might exist within
any of these entities nor of what procedures they follow.</div>
<div><br></div>
<div>I realize that this is a legacy of the original specs that you
drew from, but now might be a good time to rectify some of this.</div>
<div><br></div>
<div>For instance, you could assert that these Space Packet Protocol
Entities (SPP-RB, sec 2.1.1 and 2.3.2) do the following:</div>
<div><br></div>
<blockquote>Octet string encapsulation and extraction</blockquote>
<blockquote>Packet mux and demux for multiple paths</blockquote>
<blockquote>End to end packet routing</blockquote>
<blockquote>Stream splitting (multi-path) and forwarding</blockquote>
<blockquote>Store & forward functions</blockquote>
<blockquote><br></blockquote>
<div>These functions could be explicitly defined even though most of
them are managed and configured by mechanisms that are outside of the
entire protocol. Since there are no protocol functions defined
for any of this perhaps this all belongs in the SPP-GB rather than in
the SPP-RB. Alternatively, we could provide some simple state
machine specs for how these entities are expected to operate and this
might better clarify what is being done, where, and why.</div>
<div><br></div>
<div><u>Octet String Service</u></div>
<div><br></div>
<div>The Octet String Service (SPP-RB, sec 2.2.2.3, 3.2.3.3, and 3.4)
needs to be further clarified. As I am understanding it, this
service accepts any arbitrary string of octets, of maximum size 65536
octets (sec 3.2.3.1) such as to fit into a single packet. It
must have the the Packet Sequence Flags set to '11' (sec 4.1.2.4.2.3),
but this does not serve to distinguish that it is an Octet String.
The only way to know if it is an Octet String service is to determine
it, by management, based upon the Path ID. All of this is buried
in the text, but it is never made quite this clear. Perhaps it
needs to be clarified in Sec 2.2.2.3.</div>
<div><br></div>
<div>A string of octets longer than the max size may be transferred,
but only if the application calling the Octet String service breaks it
into a series of strings <= the maximum size and re-assembles it on
arrival. Since such an app is enjoined from using the Packet
Sequence Flags it must develop some mechanisms of its own to do this.
It is not clear why this should be required and why the Packet
Sequence Flags could not be used here as well.</div>
<div><br></div>
<div>The reference in 2.2.2.1 to Octet String service on the source
end resulting in Packet Service on the destination end only adds to
the confusion. A reference to using the Path ID to disambiguate
might help here too.</div>
<div><br></div>
<div><u>Storage of Data within Logical Data Path (LDP)</u></div>
<div><br></div>
<div>In the SPP-RB, sec 2.4.1 and 4.3.2, no mention is made of any
storage functions that may be associated with either Packet Transfer
or Packet Relaying functions, yet it is clear that some sort of data
management and associated store & forward functionality may be a
part of the operation of these functions. Since the Packet
Transfer service is explicitly defined to be asynch, out of order, no
reliability, not timely, etc (sec 2.2.1)there is an implication that
storage of data may take place at various points along the LDP.</div>
<div><br></div>
<div>In fact, in the SPP-GB, sec 2.1.2, pg 2-3, the document does
mention that LDPs provide capability for temporarily storing Space
Packets. But 2.2.3 says that the SPP does not have the
capability of managing data units. Sec 2.4.2, pg 2-8 then says
that "Store and forward" operations are performed within the
LDP. Sec 3.2 also talks of data storage functions within the SPP
Gateway or Intermediate Node. These statements within the
SPP-GB, and between this document and the SPP-RB seem to be at
odds.</div>
<div><br></div>
<div>It occurs to me that some of this ambiguity will be cleared up if
we separate the protocol functions that Space Packet Protocol Entities
carry out from the data storage functions that may be associated with
operation of some of these entities. Perhaps we need to make
explicit, in both the SPP-RB and the SPP-GB that the functions of the
LDP are performed by protocol entities and optional data storage
entities. These data storage entities may be queues, buffers, or
longer term data storage (up to a week or more) that are used by the
protocol entities as needed. We ought to at least make sure that
such store and forward functions ate treated uniformly throughout the
document set.</div>
<div><br></div>
<div><u>Service Data Units (SDU)</u></div>
<div><br></div>
<div>The term Service Data Unit is introduced in SPP-RB, sec 1.6.1.1,
but it not ever clearly defined. This same term is used both to
refer to an Octet String that is passed into the Packet Assembly
function and to refer to the Space Packets themselves (sec 2.1.2,
Table 2-1). I found this usage confusing since it meant that
SDUs (Space Packets) could encapsulate other SDUs (Octet Strings).
Since the SPP only transfers Space Packets perhaps the term SDU should
be reserved for Space Packets themselves. The descriptions
for the Octet String service could then clarify that they are just
input data units that are encapsulated to create SDUs.</div>
<div><br></div>
<div><u>Packet Secondary Header Length</u></div>
<div><br></div>
<div>The presence of a Packet Secondary Header (PSH) is indicated with
a one bit flag (sec 4.1.2.3.1.2). The header may be of
variable length, containing one or two variable length fields (sec
4.1.3.2). There appears to be no way to determine the size of
the PSH, only a means to determine if one is present. The
implication is that the definition of the structure and content of the
PSH is a local matter, set by management, and that it's form and
structure can only be determined by examination of the Path ID and
reference to some out of band information that management must
provide. This probably ought to be made explicit. The fact
that the PSH is mandatory if there is no User Data (sec 4.1.3.2.1.2)
only further serves to complicate the problem. Why is this the
case?</div>
<div><br></div>
<div><u>Time Code Field</u></div>
<div><br></div>
<div>The descriptions of time code choices in SPP-RB sec 4.1.3.2.2.3
and 4.1.3.2.2.4 seem to be inconsistent. The first says that the
selected time code shall be fixed for a given Path ID for all mission
phases. The second says that<b> if</b> the characteristics of
the time code for a given Path ID are allowed to change that they have
to obey some other rule. Shouldn't it be one way or the
other?</div>
<div><br></div>
<div><u>Definition of Synchronous</u></div>
<div><br></div>
<div>In SPP-RB, sec 1.6.1.3 there is a definition for synchronous.
This does not quite capture all of the usual semantics associated with
this term. Here are two other definitions that i found on-line,
one addressing blocking, the other addressing timing constraints.
Perhaps some combination of these is needed to clarify this.</div>
<div><br></div>
<div><font face="Courier" size="+1" color="#000000">Definition
dbooth-1</font><font face="Courier" size="+1" color="#0000EE">
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0222.html</font
><font face="Courier" size="+1" color="#000000"> Property of an
interaction whose results are directly following the<br>
interaction. An interaction between an initiator and a respondent
is</font></div>
<div><font face="Courier" size="+1" color="#000000">synchronous if the
initiator blocks some further processing while it waits for a
corresponding action, response or acknowledgement from the
respondent.<br>
<br>
----</font></div>
<div><font face="Courier" size="+1" color="#000000">Definition
walden-1</font><font face="Courier" size="+1" color="#0000EE">
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0326.html</font
><font face="Courier" size="+1" color="#000000"> Synchronous, then,
places a constraint on a response such that the response must be
received within a strictly or loosely defined time quantum (strict vs
lax synchrony), or else the exchange fails. Asynchronous differs in
that no amount of elapsed time signals the failure of the
exchange.</font></div>
<div><br></div>
<div><u>Other SPP-GB Issues</u></div>
<div><br></div>
<div>Sec 1.4, pg 1-2, Two different definitions for the term Space
Packet Protocol, the second probably should be Space Packet Protocol
Entity.</div>
<div><br></div>
<div>Sec 2.3.2, pg 2-5, pp 2, Probably ought to refer to the fact that
other reliability mechanisms are also available at the link
layer.</div>
<div><br></div>
<div>Sec 2.4.2, pg 2-7, pp 1, Not clear that it is useful to say that
preprocessing may discard useless images. Does not add to
discussion at hand and may offend some readers.</div>
<div><br></div>
<div>Sec 3.2 and 3.3, pgs 3-2,3; Suggest altering or adding at
least one diagram that explicitly shows a Data Store function being
used to implement store and forward operations.</div>
<div><br></div>
<div>Sec 3.3, Pg 3-4, fig 3-4,5; Not really clear what
distinction you are trying to make with these two diagrams. Fig
3-4 shows nodes in a Connectivity View. SAPs would not normally be
shown on such a diagram, but PORTS might be (as in the typical
Component / Connector diagram). Fig 3-5 shows Functions with the LDP
shown as an abstract protocol function. Here the SAPs make sense
and they would probably correspond to the service primitives in
SPP-RB, sec 3.3 and 3.4. They would be clearer if shown on some
diagram like fig 2-3 or 2-5 from the SPP-RB.</div>
<div><br></div>
<div>Sec 4.1, pg 4-1; The SPP is really an application layer
artifact in that it is used for end to end transmission of data
between applications. As noted in the first comment above, the
most concrete parts of the spec are about data structure rather than
anything else that would normally be thought of as a protocol / state
machine. If we are going to tighten up the definition of how the
protocol entities operate, and provide anything like even a simple
state machine descriptions, then this discussion would make more
sense.</div>
<div><br></div>
<div>Here, and in sec 4.2, we could include some simple diagrams that
would relate the packet protocol entities to different underlying
transfer protocols, like paths on-board, TM/TC on the space link, and
TCP/IP on the ground (with or without SLE).</div>
<div><br></div>
<div>I hope you find these comments useful. Please let me know
if anything is unclear.</div>
<div><br></div>
<div>Very best regards, Peter</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div>At 8:47 PM +0900 8/12/03, Takahiro Yamada wrote:</div>
<blockquote type="cite" cite>Dear CESG members, Space Packet Protocol
WG members, and Space Link Protocols WG members:<br>
<br>
I have written a draft Green Book on the Space Packet Protocol, which
can be found at<br>
<br>
http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-324</blockquote>
<blockquote type="cite" cite><br>
This book should have been written together with the Red Book on the
same protocol, but unfortunately I couldn't find time to do so.<br>
<br>
I'd appreciate it very much if you could review it together with the
Red Book, Issue 1A, which can be found in the same collection.<br>
<br>
I've found that this Green Book is listed as a deliverable of the
Space Link Protocols WG, not of the Space Packet Protocol WG, but I
think it should belong to the Space Packet Protocol WG. If you
agree with me, please correct the charters accordingly.<br>
<br>
Since the Space Packet Protocol is one of the primary products of
CCSDS, I'd like the draft Green Book to be reviewed by as many people
as possible. I'd appreciate it if you could distribute the draft
to any people who may be interested in reviewing it.<br>
<br>
I will write another Green Book on the Space Data Link Protocols in
September.<br>
<br>
Best regards,<br>
Takahiro Yamada, ISAS.<br>
<br>
<br>
_______________________________________________<br>
CESG mailing list<br>
CESG@mailman.ccsds.org<br>
http://mailman.ccsds.org/mailman/listinfo/cesg</blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><font face="Geneva" size="-1"
color="#000000"
>_______________________________________________________________</font
><br>
</div>
<div><font face="Geneva" size="-1" color="#000000">Peter
Shames</font></div>
<div><font face="Geneva" size="-1" color="#000000">Manager - JPL
Information Systems Standards Program</font></div>
<div><font face="Geneva" size="-1" color="#000000">InterPlanetary
Network and Information Systems Directorate</font></div>
<div><font face="Geneva" size="-1" color="#000000">Jet Propulsion
Laboratory, MS 301-265<br>
California Institute of Technology<br>
Pasadena, CA 91109 USA</font><br>
</div>
<div><font face="Geneva" size="-1" color="#000000">Telephone: +1 818
354-5740, Fax: +1 818 393-1333<br>
<br>
Internet: Peter.Shames@jpl.nasa.gov<br>
___________________________________________________________</font><font
face="Geneva" size="+1" color="#000000">____</font></div>
<div><font face="Geneva" size="-1" color="#000000">"We shall not
cease from exploration, and the end of all our exploring</font></div>
<div><font face="Geneva" size="-1" color="#000000">will be to arrive
at where we started, and know the place for the first
time"</font></div>
<div><font face="Geneva" size="-1" color="#000000"><br></font></div>
<div><font face="Geneva" size="-1"
color="#000000"
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span> T.S. Eliot</font></div>
</body>
</html>