[Cesg-all] Re: Rick Schnurr's comments re: AOS Pink Sheets
Fred Brosi
brosi@gst.com
Fri, 25 Jul 2003 11:19:56 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_005B_01C3529E.AD5E61A0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
CSS will have a SLE Service Management WG meeting here at GST next week. We
will look at this issue. from a management point of view.
Wearing my (very old and tattered) Panel 1 hat, I have a couple of thoughts
on this:
1. Just personal opinion, but I don't like to see the bits of data fields
spread around. That's OK to make something work for the next mission, before
the standard can be upgraded, but in an international standard, it should be
a last resort.
2. There are lots of ways to accomplish the goal of "more data before the
numbering becomes ambiguous". It's not clear that these have been
identified, let alone evaluated.
3. This sort of thing illustrates the dark side of following the
frequently-given advice to let "real mission requirements" drive standards.
When we worked telecommand and, later, SLAP, we were forced to make our
sequence numbers shorter--"we'll never have rates so high or delays so long
that we need so many bits!" was the chant. Not that there aren't a LOT of
good reasons to learn and meet current mission requirements, but meeting
longer-term requirements and lowering total cost generally isn't one of
them.
-Fred Brosi
-----Original Message-----
From: cesg-all-admin@mailman.ccsds.org
[mailto:cesg-all-admin@mailman.ccsds.org]On Behalf Of Adrian J. Hooke
Sent: Friday, July 25, 2003 10:33 AM
To: CCSDS Engineering Steering Group - All
Subject: Re: [Cesg-all] Re: Rick Schnurr's comments re: AOS Pink Sheets
At 04:47 AM 7/25/2003, Takahiro Yamada wrote:
The AOS receiver has to know several things before being able to receive
frames (for example, frame length). Therefore, I think the counter length
can be a managed parameter (like the frame length).
It certainly *can* be a managed parameter, but then so can many other
fields that are presently explicitly signaled. [For instance, why not take
out the Spacecraft ID and the Signalling Field and shorten the frame header
by two octets (33%)]?
The question is whether it *should* be a managed parameter? Is increasing
the complexity of the manual set-up something that we should be striving for
in the future, or should we be aiming to increase the level of
protocol-driven automation? I'd like to hear from the CSS Area on this.
I would prefer to specify the extended counter length separately from
the proposed retransmission procedure because AOS can, in principle, have
multiple retransmission procedures.
Each of them (in principle) identified by "management" and each of them
(in principle) having its own unique managed counter?
Let me ask Greg a question here: is he proposing to extend this counter
because there is universal consensus that this is independently a good thing
for humanity, or is he extending it because he thinks that he will need it
as part of some future, yet-to-be-defined retransmission scheme - or, in
principle, multiple future, yet-to-be-defined retransmission schemes?
Best regards
Adrian
------=_NextPart_000_005B_01C3529E.AD5E61A0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 5.50.4919.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D510275614-25072003>CSS=20
will have a SLE Service Management WG meeting here at GST next week. We =
will=20
look at this issue. from a management point of view.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D510275614-25072003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D510275614-25072003>Wearing my (very old and tattered) Panel 1 =
hat, I have=20
a couple of thoughts on this:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D510275614-25072003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D510275614-25072003>1.=20
Just personal opinion, but I don't like to see the bits of data fields =
spread=20
around. That's OK to make something work for the next mission, before =
the=20
standard can be upgraded, but in an international standard, it should be =
a last=20
resort.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D510275614-25072003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D510275614-25072003>2.=20
There are lots of ways to accomplish the goal of "more data before the =
numbering=20
becomes ambiguous". It's not clear that these have been =
identified, let=20
alone evaluated.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D510275614-25072003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D510275614-25072003>3.=20
This sort of thing illustrates the dark side of following the =
frequently-given=20
advice to let "real mission requirements" drive standards. When we =
worked=20
telecommand and, later, SLAP, we were forced to make our sequence =
numbers=20
shorter--"we'll never have rates so high or delays so long that we need =
so many=20
bits!" was the chant. Not that there aren't a LOT of good reasons =
to learn=20
and meet current mission requirements, but meeting longer-term =
requirements and=20
lowering total cost generally isn't one of them.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D510275614-25072003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D510275614-25072003>-Fred=20
Brosi</SPAN></FONT></DIV>
<BLOCKQUOTE>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B>=20
cesg-all-admin@mailman.ccsds.org=20
[mailto:cesg-all-admin@mailman.ccsds.org]<B>On Behalf Of </B>Adrian J. =
Hooke<BR><B>Sent:</B> Friday, July 25, 2003 10:33 AM<BR><B>To:</B> =
CCSDS=20
Engineering Steering Group - All<BR><B>Subject:</B> Re: [Cesg-all] Re: =
Rick=20
Schnurr's comments re: AOS Pink Sheets<BR><BR></FONT></DIV><FONT=20
color=3D#0000ff>At 04:47 AM 7/25/2003, Takahiro Yamada wrote:<BR>
<BLOCKQUOTE class=3Dcite cite type=3D"cite">The AOS receiver has to =
know several=20
things before being able to receive frames (for example, frame =
length). Therefore, I think the counter length can be a managed =
parameter=20
(like the frame length).</FONT> </BLOCKQUOTE><BR>It certainly *can* =
be a=20
managed parameter, but then so can many other fields that are =
presently=20
explicitly signaled. [For instance, why not take out the Spacecraft ID =
and the=20
Signalling Field and shorten the frame header by two octets =
(33%)]?<BR><BR>The=20
question is whether it *should* be a managed parameter? Is increasing =
the=20
complexity of the manual set-up something that we should be striving =
for in=20
the future, or should we be aiming to increase the level of =
protocol-driven=20
automation? I'd like to hear from the CSS Area on this.<BR><BR>
<BLOCKQUOTE class=3Dcite cite type=3D"cite"><FONT color=3D#0000ff>I =
would prefer=20
to specify the extended counter length separately from the proposed=20
retransmission procedure because AOS can, in principle, have =
multiple=20
retransmission procedures. </FONT></BLOCKQUOTE><BR>Each of them (in =
principle)=20
identified by "management" and each of them (in principle) having its =
own=20
unique managed counter? <BR><BR>Let me ask Greg a question here: is =
he =20
proposing to extend this counter because there is universal consensus =
that=20
this is independently a good thing for humanity, or is he extending it =
because=20
he thinks that he will need it as part of some future, =
yet-to-be-defined=20
retransmission scheme - or, in principle, multiple future, =
yet-to-be-defined=20
retransmission schemes?<BR><BR>Best=20
regards<BR>Adrian<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_005B_01C3529E.AD5E61A0--