[Cesg-all] Re: Rick Schnurr's comments re: AOS Pink Sheets

Fri, 25 Jul 2003 07:32:40 -0700

--=====================_1556874796==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

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

--=====================_1556874796==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 04:47 AM 7/25/2003, Takahiro Yamada wrote: 
<blockquote type=cite class=cite cite>The AOS receiver has to know
several things before being able to receive&nbsp; frames (for example,
frame length). Therefore, I think the counter length can be a managed
parameter (like the frame length). </blockquote> 
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. 
<blockquote type=cite class=cite cite>I would
prefer to specify the extended counter length separately from the
proposed retransmission procedure because AOS can, in principle, have
multiple retransmission procedures. </blockquote> 
Each of them (in principle) identified by &quot;management&quot; and each
of them (in principle) having its own unique managed counter? 
Let me ask Greg a question here: is he&nbsp; 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 
</html>

--=====================_1556874796==_.ALT--