[Discuss-gnuradio] V3 Comments on "BBN's Proposed extensions for data networking"

[Michael Dickens]

Dave - Working on v3 of this document.  There are some changes from  
the previous version which greatly improve clarity!  Thanks!  Here  
are some more suggestions, comments, questions, and thoughts. - MLD

p60, 4.2: "The Media Access Control (MAC) layer needs low-latency  
transmission control -- faster than the FIFO processing currently  
implemented in GNU Radio flow graphs." : How about just removing the  
reference to GNU Radio's flow graphs (or maybe, moving it to the GR  
baseline section), since it's the only "comparison" in that whole  
paragraph.  You can certainly add something else on the tail of that  
short sentence, but it needs to be an extension which describes the  
"low-latency transmission control".  If this concept is solely for  
prioritizing messages, then you could make it something like "The  
Media Access Control (MAC) layer needs low-latency transmission  
control, allowing for high-priority messages to propagate through a  
set of m-blocks undisturbed so-as to minimize computational latency."  
if you felt that was appropriate.  If, for the purposes of your  
description, this concept is more than that, then add something  
else.  Either way, removing the comparison IMHO is useful.

p61, REQ 4.10: I would add the words "the current" to "GR Framework"  
to make it explicit what you're not going to change.

p61, REQ 4.13, 4.14: Could these be combined, or 4.14 just removed?   
What is the difference, since the latter seems to be a subset of the  
former.  What are the concepts supposed to be, as they seem  
duplicative to me?

p63, 4.5.1; and p70, 4.8.1: It would probably be worth noting that in  
the gr-stuff world there is no generic built-in functionality for  
stopping computations to allow for higher-priority computations to  
take place (even if the gr-scheduler were written to handle  
prioritization) [NOTE: it would be possible for individual gr-blocks  
to do this, but none at this time do that I know of].  Thus -any- use  
of the gr-scheduler must wait until completion of all data being  
processed.  This goes for m-blocks too when encapsulating a gr-flow- 
graph, not just gr_blocks and flow-graphs standing alone.

p64: "systolic": I still feel it just doesn't work.  Yes, I read what  
you wrote about the "pulsing" nature of the GR scheduler, of which I  
agree that's pretty much how it works.  But "systolic", at least in  
my understanding and def'n reading, means contraction/compression  
(specifically of the heart muscles, but could be others) ... the  
result of which is the pulsing nature of blood-flow.  The pulsing is  
a result of the systole, but isn't what the systole does or is.  I  
still feel that "systematic" or "round robin" or even (arranged,  
methodic, orderly, well-ordered, well-regulated) might be better when  
used appropriately.

Also, the whole discussion of packet radio requirements doesn't  
really fit into the GR baseline, and should instead probably be in  
4.3, or at least elsewhere.

p66, 4.6.3: I'd move the second paragraph to the second or third  
sentence of the first paragraph ... just fits there better.

* Also, I don't understand "m-block s may be enclosed within a single  
m-block and treated as a single entity." down to the flow-graph  
stuff  From our previous discussion, the aggregation is purely  
symbolic in nature ... there is still a virtual, possibly dynamic,  
graph upon which the m-scheduler must work.  Thus, how can  
aggregation make a "single entity" w/r.t. the m-scheduler?   
Aggregation implies to me that the primary m-block's "handle_message"  
is called, and then that m-block deals with all the aggregated  
internal m-blocks (and gr_blocks, if any).

* Regarding: "Primitives will be provided to allow the connection of  
internal components of the m-block to each other and to external  
interfaces."   ... So the m-block class will provide the "graph"  
functionality, instead of having it be an external entity as is  
currently done in GR?  'tis a good idea, IMHO.

p67, 4.6.4: " transformed by the blocks in the flow graph."  --> "any  
internal flow graph".  I assume you're referring to the gr_block flow- 
graph here ...

p67: 4.6.7: which "flow graph" is this referring to?  Looks like the  
m-block stuff, which isn't a flow graph at all, so I think this needs  
to be changed.  You might want to do a global search for this term to  
make sure all references are appropriate, and change those which are  
not.

p68, 4.8.1; and p74, 4.8.4: How can an m-block have zero ports?  I  
thought that all data / metadata / signals / whatever were  
transported via these ports.  Without a port of any type, what can an  
m-block do?

p68&70, 4.8.1: How can you implement "a mechanism is required that  
will allow m-block s to relinquish control of a processor after a  
certain number of processor cycles have been used" for a gr-flow- 
graph and guarantee that the internal flow-graph's memory is  
maintained?  How is this implemented in general?  I guess you could  
start a new thread, which would execute for X us or ms, but that  
seems like a costly overhead when "real-time" needs very low  
latency.  You might want to tweak the last paragraph, first sentence,  
to state that the gr_single... will run all the data through  
regardless of the number of processor cycles it takes, in order to  
guarantee memory coherency (or something like that).

p70, 4.8.2.2: "Within an m-block, data is moved through the GNU Radio  
flow graph using a GNU Radio scheduler that runs within its own  
thread of execution."  ... this doesn't sound correct, regarding the  
previous discussion.

Also, looks like a new number (or more) is missing, starting with  
"However, information ...".  Or, well, something is just wrong with  
the rest of this section ... seems non-coherent.  Could you please  
number / reorganize / rewrite / make more coherent?

p75, 4.9.5: Could you make a drawing depicting replicated ports?   
Might add insight for some folks.

p76, 4.9.11: "Messages arriving at an unconnected relay port are  
discarded."  ... while it's nice to have unconnected ports, this  
takes extra processing to deal with.  Is it possible to never have  
unconnected ports, and/or to always make use of all ports?  Or in the  
dynamic graphing, is this just a possibility which can happen and  
thus needs to be considered?

p77, 4.9.11: "These ports are not visible from the outside of the m- 
block, and are not a part of the peer interface." ... what does  
"visible" mean here?  I thought that all m-blocks are dealt with by  
the m-scheduler?  I think what you're trying to say is that any  
internal ports will be defined solely inside the definition of the  
enclosing m-block, when using this semi-formal description, and hence  
will not be available for connections outside of the enclosing m- 
block.  Yes?

p77, (4.14-4.16):  Would it make more sense to first state that
     peer interface  = external end ports  U  relay ports
then go on with the current 4.14 and 4.15 (if desired, or not).