WilliamAtSamraksh commented 8 years ago

Tuscarora has methods SendData and BroadcastData. In CSMA we have Send; Broadcast is a Send with a special address of MAC.AddressType.BROADCAST (65535). In OMAC we only have Send.

Suppose we need to broadcast. In the case of CSMA, Tuscarora's BroadcastData can be handled by CSMA. In the case of OMAC it can be simulated in Tuscarora via unicast to all neighbors. This of course is not true broadcast--neighbors are not all getting the same message at the same time--but it satisfies the needs of protocols like Collection Tree to advertise availability as a parent.

So to accommodate Tuscarora I suggest changing Samraksh.Net as follows:

Create interface IMACBroadcast that inherits from IMAC and adds a Broadcast method.
Create class MACBaseBroadcast that inherits from MACBase and implements IMACBroadcast.
Change CSMA to instantiate MACBaseBroadcast so that is has separate Send and Broadcast methods, and does not treat 65535 as anything special. Or, honor 65535 and obsolete MAC.AddressType.BROADCAST.

These changes mean that when Tuscarora is instantiated with OMAC or CSMA it knows whether or not the MAC has a Broadcast method and can handle it accordingly.

AnanthAtSamraksh commented 8 years ago

How is this different from #392 ?

WilliamAtSamraksh commented 8 years ago

392 suggested adding Broadcast to OMAC directly. This suggests using Tuscarora to handle it. There's no need to add it to OMAC if we can accomplish the same thing in Tuscarora.

mukundansridharan commented 8 years ago

When routing is implemented on Tuscarora, the routing developer is strongly discouraged to use Broadcast. Broadcast is a use at your own risk feature in Tuscarora. Broadcast can also be turned off at policy level and made to return false always. Adding broadcast directly to OMAC sends the opposite signal to the developer.

From: William Leal [mailto:notifications@github.com] Sent: Tuesday, April 26, 2016 12:32 PM To: Samraksh/MF MF@noreply.github.com Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

392https://github.com/Samraksh/MF/issues/392 suggested adding Broadcast to OMAC directly. This suggests using Tuscarora to handle it. There's no need to add it to OMAC if we can accomplish the same thing in Tuscarora.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-214803172

WilliamAtSamraksh commented 8 years ago

So we're agreed, yes? Broadcast is not a part of OMAC and is handled by Tuscarora (with the caveats you cited).

KennethAtSamraksh commented 8 years ago

This is not about where broadcast is implemented. In a low power system there are either no power wins for realistic assumptions about the channel statistics and or only very small power wins for Gaussian IID assumptions. So just do point to point communication at the

Kenneth W. Parker, Ph.D.

From: William Leal [mailto:notifications@github.com] Sent: Tuesday, April 26, 2016 1:26 PM To: Samraksh/MF MF@noreply.github.com Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

So we're agreed, yes? Broadcast is not a part of OMAC and is handled by Tuscarora (with the caveats you cited).

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-214818921

AnishAtSamraksh commented 8 years ago

Emulation via point to point is what Bill meant. Language issues aside.

From: Kenneth W. Parker [mailto:notifications@github.com] Sent: Tuesday, April 26, 2016 1:56 PM To: Samraksh/MF MF@noreply.github.com Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

This is not about where broadcast is implemented. In a low power system there are either no power wins for realistic assumptions about the channel statistics and or only very small power wins for Gaussian IID assumptions. So just do point to point communication at the

Kenneth W. Parker, Ph.D.

From: William Leal [mailto:notifications@github.com] Sent: Tuesday, April 26, 2016 1:26 PM To: Samraksh/MF MF@noreply.github.com<mailto:MF@noreply.github.com> Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

So we're agreed, yes? Broadcast is not a part of OMAC and is handled by Tuscarora (with the caveats you cited).

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-214818921

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-214828343

KennethAtSamraksh commented 8 years ago

For language purposes the interface called broadcast in Tuscarora doesn’t do point-to-point emulation … it needs to be done in the application …

WilliamAtSamraksh commented 8 years ago

My original post conflated 2 concerns: (1) What Tuscarora does with Broadcast and (2) how it knows to make the choice. As to the first, doing Tuscarora Broadcast for OMAC could result in simulated broadcast or in an error response of some sort. This is secondary and can be sorted out later.

Stripped of the first concern, my proposal gives a way for Tuscarora to know whether a MAC supports native broadcast or not. Focusing on just that, what do you think?

KennethAtSamraksh commented 8 years ago

Bill, no rush, but can you summarize our verbal conversation for this thread.

WilliamAtSamraksh commented 8 years ago

Here's what I understood from my conversation with Kenneth. Corrections welcome, of course.

Tuscarora Broadcast sends a single message and requires acknowledgements from each neighbor (i.e., each node that's in range). There are two issues:

If a node has many neighbors then acks will flood the sender and get lost. There are specialized solutions to this problem but none that we offer.
OMAC does not support a mode in which all neighbors can hear a message at the same time.

Consequently, we do not support Broadcast.

CSMA has something called "Broadcast". Since it does not receive acks from neighbors, it does not qualify as Tuscarora Broadcast and would be better called something like "Spray". Spray is useful for discovery and little else. It should not be used in any pattern (protocol) except for very rare ones in which ack is forbidden (such as the need to maintain radio silence in the field). Consequently,

Spray should be eliminated from CSMA.
The present use of Spray to advertise a node's availability as a parent in, for example, Collection Tree Protocol (CTP) should be replaced by unicast to each neighbor.

There's a power question. Spray for CSMA takes less power than unicast to neighbors. CSMA is typically dominated by the power required for listening. In CTP the advertisement is done at low frequency, so the savings from Spray is minimal.

AnishAtSamraksh commented 8 years ago

 Does dropping Spray contradict our promise to DARPA?

 Low duty cycle implementation should not use CSMA (it should use OMAC). But high duty cycle implementation should use CSMA.  And, for high duty cycle, constants matter wrt capacity, so spray ought to be part of CSMA.  I would argue that we not lose that type of .NOW user at this stage of Samraksh.

 For the .NOW framework realization, are their options to deal with space sharing between patterns and framework?

From: William Leal [mailto:notifications@github.com] Sent: Thursday, April 28, 2016 1:34 PM To: Samraksh/MF MF@noreply.github.com Cc: Anish Arora Anish.Arora@samraksh.com; Comment comment@noreply.github.com Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

Here's what I understood from my conversation with Kenneth. Corrections welcome, of course.

Tuscarora Broadcast sends a single message and requires acknowledgements from each neighbor (i.e., each node that's in range). There are two issues:

· If a node has many neighbors then acks will flood the sender and get lost. There are specialized solutions to this problem but none that we offer.

· OMAC does not support a mode in which all neighbors can hear a message at the same time.

Consequently, we do not support Broadcast.

CSMA has something called "Broadcast". Since it does not receive acks from neighbors, it does not qualify as Tuscarora Broadcast and would be better called something like "Spray". Spray is useful for discovery and little else. It should not be used in any pattern (protocol) except for very rare ones in which ack is forbidden (such as the need to maintain radio silence in the field). Consequently,

· Spray should be eliminated from CSMA.

· The present use of Spray to advertise a node's availability as a parent in, for example, Collection Tree Protocol (CTP) should be replaced by unicast to each neighbor.

There's a power question. Spray for CSMA takes less power than unicast to neighbors. CSMA is typically dominated by the power required for listening. In CTP the advertisement is done at low frequency, so the savings from Spray is minimal.

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-215504115

mukundansridharan commented 8 years ago

I agree with Anish. Always on MACs like csma should continue to support Broadcast (and we should not change its name to spray, because it is what the community understands as broadcast), primarily because they don’t provide any special discovery or estimation apis and assume the traditional broadcast will be used for those purposes.

If we keep broadcast for csma, from a user perspective one would argue that code written on csma will not port directly to omac and that would be true and that’s why you should write on top Tuscarora and not directly on top of MACs.

The key issue is not at the MAC layer, rather at the framework layer.

Does dropping Spray contradict our promise to DARPA? I don’t think so and (I think) Ken doesn’t think so either. We haven’t promised DARPA to freeze APIs and the need to add broadcast was not DARPA’s idea to begin with, it was more to satisfy LL

So here is my proposal:

   We continue to keep Broadcast as optional method in the Waveform/MAC interface

   We drop Broadcast/Spray all together from the framework interface

   What use is Broadcast in Waveform/MAC if not exposed to routing? Well, the framework/MAC can use it for estimation/discovery and other control purposes.

There is a different approach one could take which is to expose at the framework a special “Spray” link for each waveform as part of the neighbor table and publish a different “cost” as against a unicast link. This cost could consider the emulation cost at the framework. A sophisticated emulation at the framework can be written which would take a parameter and send that many randomized unicasts to neighbors instead of just one that Ken suggested. A routing would have to consider the cost of using a the spray link as against using multiple unicast itself. On a MAC that supports native broadcast, the spary link cost would be same as unicast cost. While, semantically this is an elegant solution, in practice for purposes of code compatibility most patterns would simply ignore the cost and keep using Spray api which is what we are trying to prevent in the first place.

From: AnishAtSamraksh [mailto:notifications@github.com] Sent: Friday, April 29, 2016 10:00 AM To: Samraksh/MF MF@noreply.github.com Cc: Mukundan Sridharan Mukundan.Sridharan@samraksh.com; Comment comment@noreply.github.com Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

Does dropping Spray contradict our promise to DARPA?
Low duty cycle implementation should not use CSMA (it should use OMAC). But high duty cycle implementation should use CSMA. And, for high duty cycle, constants matter wrt capacity, so spray ought to be part of CSMA. I would argue that we not lose that type of .NOW user at this stage of Samraksh.
For the .NOW framework realization, are their options to deal with space sharing between patterns and framework?

From: William Leal [mailto:notifications@github.com] Sent: Thursday, April 28, 2016 1:34 PM To: Samraksh/MF MF@noreply.github.com<mailto:MF@noreply.github.com> Cc: Anish Arora Anish.Arora@samraksh.com<mailto:Anish.Arora@samraksh.com>; Comment comment@noreply.github.com<mailto:comment@noreply.github.com> Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

Here's what I understood from my conversation with Kenneth. Corrections welcome, of course.

Tuscarora Broadcast sends a single message and requires acknowledgements from each neighbor (i.e., each node that's in range). There are two issues:

· If a node has many neighbors then acks will flood the sender and get lost. There are specialized solutions to this problem but none that we offer.

· OMAC does not support a mode in which all neighbors can hear a message at the same time.

Consequently, we do not support Broadcast.

CSMA has something called "Broadcast". Since it does not receive acks from neighbors, it does not qualify as Tuscarora Broadcast and would be better called something like "Spray". Spray is useful for discovery and little else. It should not be used in any pattern (protocol) except for very rare ones in which ack is forbidden (such as the need to maintain radio silence in the field). Consequently,

· Spray should be eliminated from CSMA.

· The present use of Spray to advertise a node's availability as a parent in, for example, Collection Tree Protocol (CTP) should be replaced by unicast to each neighbor.

There's a power question. Spray for CSMA takes less power than unicast to neighbors. CSMA is typically dominated by the power required for listening. In CTP the advertisement is done at low frequency, so the savings from Spray is minimal.

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-215504115

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-215724638

KennethAtSamraksh commented 8 years ago

A Waveform/MAC either needs to expose spray or discovery. A waveform that has discoverer doesn’t need spray. In that since it would be OK to drop spray from our CSM because it already exposes discovery.

But I’m OK with keeping it. A user that is not using Tuscarora and is writing directly to the MAC might want spray. So if the waveform exposes something called broadcast, it’s OK to keep it.

I’m not OK with changing the meaning of broadcast in Tuscarora, it already supports multi-node send.

I think we can say that broadcast was dropped only in the Golden Release, because it is the more academically pure form of the framework, it’s kept in the military version, because they have special needs (like radio silence).

I’m not OK with routine internal use of non-ACKed communication like spray. ACKs make or break for Anti-Jamming (AJ) systems. So we should develop the discipline of trying to only use ACKed communication. When this causes problems we should learn from those problems, not revert back to things like spray. The learning may matter in our ability to capture some military work.

Kenneth W. Parker, Ph.D.

From: MukundanAtSamraksh [mailto:notifications@github.com] Sent: Friday, April 29, 2016 11:13 AM To: Samraksh/MF MF@noreply.github.com Cc: Kenneth Parker Kenneth.Parker@samraksh.com; Comment comment@noreply.github.com Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

I agree with Anish. Always on MACs like csma should continue to support Broadcast (and we should not change its name to spray, because it is what the community understands as broadcast), primarily because they don’t provide any special discovery or estimation apis and assume the traditional broadcast will be used for those purposes.

If we keep broadcast for csma, from a user perspective one would argue that code written on csma will not port directly to omac and that would be true and that’s why you should write on top Tuscarora and not directly on top of MACs.

The key issue is not at the MAC layer, rather at the framework layer.

Does dropping Spray contradict our promise to DARPA? I don’t think so and (I think) Ken doesn’t think so either. We haven’t promised DARPA to freeze APIs and the need to add broadcast was not DARPA’s idea to begin with, it was more to satisfy LL

So here is my proposal:

We continue to keep Broadcast as optional method in the Waveform/MAC interface
We drop Broadcast/Spray all together from the framework interface
What use is Broadcast in Waveform/MAC if not exposed to routing? Well, the framework/MAC can use it for estimation/discovery and other control purposes.

There is a different approach one could take which is to expose at the framework a special “Spray” link for each waveform as part of the neighbor table and publish a different “cost” as against a unicast link. This cost could consider the emulation cost at the framework. A sophisticated emulation at the framework can be written which would take a parameter and send that many randomized unicasts to neighbors instead of just one that Ken suggested. A routing would have to consider the cost of using a the spray link as against using multiple unicast itself. On a MAC that supports native broadcast, the spary link cost would be same as unicast cost. While, semantically this is an elegant solution, in practice for purposes of code compatibility most patterns would simply ignore the cost and keep using Spray api which is what we are trying to prevent in the first place.

From: AnishAtSamraksh [mailto:notifications@github.com] Sent: Friday, April 29, 2016 10:00 AM To: Samraksh/MF MF@noreply.github.com<mailto:MF@noreply.github.com> Cc: Mukundan Sridharan Mukundan.Sridharan@samraksh.com<mailto:Mukundan.Sridharan@samraksh.com>; Comment comment@noreply.github.com<mailto:comment@noreply.github.com> Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

Does dropping Spray contradict our promise to DARPA?
Low duty cycle implementation should not use CSMA (it should use OMAC). But high duty cycle implementation should use CSMA. And, for high duty cycle, constants matter wrt capacity, so spray ought to be part of CSMA. I would argue that we not lose that type of .NOW user at this stage of Samraksh.
For the .NOW framework realization, are their options to deal with space sharing between patterns and framework?

From: William Leal [mailto:notifications@github.com] Sent: Thursday, April 28, 2016 1:34 PM To: Samraksh/MF MF@noreply.github.com<mailto:MF@noreply.github.com<mailto:MF@noreply.github.com%3cmailto:MF@noreply.github.com>> Cc: Anish Arora Anish.Arora@samraksh.com<mailto:Anish.Arora@samraksh.com<mailto:Anish.Arora@samraksh.com%3cmailto:Anish.Arora@samraksh.com>>; Comment comment@noreply.github.com<mailto:comment@noreply.github.com<mailto:comment@noreply.github.com%3cmailto:comment@noreply.github.com>> Subject: Re: [Samraksh/MF] Adjusting Samraksh.Net interfaces for Tuscarora (#396)

Here's what I understood from my conversation with Kenneth. Corrections welcome, of course.

Tuscarora Broadcast sends a single message and requires acknowledgements from each neighbor (i.e., each node that's in range). There are two issues:

· If a node has many neighbors then acks will flood the sender and get lost. There are specialized solutions to this problem but none that we offer.

· OMAC does not support a mode in which all neighbors can hear a message at the same time.

Consequently, we do not support Broadcast.

CSMA has something called "Broadcast". Since it does not receive acks from neighbors, it does not qualify as Tuscarora Broadcast and would be better called something like "Spray". Spray is useful for discovery and little else. It should not be used in any pattern (protocol) except for very rare ones in which ack is forbidden (such as the need to maintain radio silence in the field). Consequently,

· Spray should be eliminated from CSMA.

· The present use of Spray to advertise a node's availability as a parent in, for example, Collection Tree Protocol (CTP) should be replaced by unicast to each neighbor.

There's a power question. Spray for CSMA takes less power than unicast to neighbors. CSMA is typically dominated by the power required for listening. In CTP the advertisement is done at low frequency, so the savings from Spray is minimal.

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-215504115

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-215724638

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/Samraksh/MF/issues/396#issuecomment-215749140

Samraksh / eMote

Adjusting Samraksh.Net interfaces for Tuscarora #396

392 suggested adding Broadcast to OMAC directly. This suggests using Tuscarora to handle it. There's no need to add it to OMAC if we can accomplish the same thing in Tuscarora.

392https://github.com/Samraksh/MF/issues/392 suggested adding Broadcast to OMAC directly. This suggests using Tuscarora to handle it. There's no need to add it to OMAC if we can accomplish the same thing in Tuscarora.