Subject: Re: Re: mackiller under linux

From: David <[email-masked]>
Date: Thu, 16 Aug 2001 17:33:12 +0800

Fred,
  You comment is great. In this Mackiller version, First, it drop all , then you can use mac_client -s 0A:02:02:02:02:02 to accept packet from that mac. It's easy to build a network link in emulation. If you make up "accept all" policy, then it's difficult to build  net link between tow nodes,  you have to deny all other MAC addresses. If the number of nodes is more than ten, it's really a hard work.  As you mention, the best way is let mackiller only to do mac killing on certain interface.  If you think that is useful, I will consider to add that in mackiller.
	I wrote a letter on month ago about large scale ad hoc emualtion on ethernet. mackiller is only a part of that project. The project include scenario generator compatible with NS, network performance emulation in linux kernel, such as link quality, delay, drop. As you said,
hidden terminals is a big problem. But if you want make the emulation complex enough, I think you can make a hidden termials condition on that emulation envirement. A central topology control is needed here. Although the physical communication at same time is impossible, but we can deal that at the logical layer, just as NS do it. But I think it will be more complex than NS in realization, for it's distribution computatioin. As CSMA/CA+RTS+CTS+ACK can solve the hidden termials good enough, I think it is not a main problem in MANET. The main problem is the efficient of routing algrithm under high changing topology, such as in tanks group.
    But I think in current condition(specially in my lab), we lack money to buy so many laptop and wavelan card, it is impossible for me to do large sclale ad hoc examination. Emulation based on ethernet is a good way. More than 100 nodes can be used in a emulation process. And the traffic pattern is real. In my opinion, ME( MPRN EMUALTION) will do better than NS in Ad hoc study.

Any comment will be appreciated.

David

Computer Science Department

Beijing Institute of Technology (http://www.bit.edu.cn)

China

>David,
>
>I read the code, and it looks like it could be a useful package for
>testing the correctness of an ad-hoc routing protocol. I would have
>preferred your setting the default behavior to "accept all" rather
>than the "default drop all" policy you are using, since it would
>allow normal operation for non-MANET interfaces (e.g. if a node has
>both an IEEE 802.11 interface for MANET operation and an Ethernet
>interface for normal Internet access.)
>
>One thing to note about emulating an ad-hoc network using something
>like mackiller, however, is that such an emulated network *must not*
>be used for performance evaluation. Reason being is that, on data
>links like IEEE 802.11, mimicing multi-hop paths by selectively
>dropping packets received with particular MAC addresses is *not the
>same thing* as having *true* multi-hop paths in which some nodes are
>actually hidden terminals with respect to others. You might want to
>point this out in your 'README'.
>
>Fred Templin
>[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 16 Aug 2001 10:28:12 -0700

David,

David wrote:
> 
> Fred,
>   You comment is great. In this Mackiller version, First, it drop all ,
> then you can use mac_client -s 0A:02:02:02:02:02 to accept packet from that
> mac. It's easy to build a network link in emulation. If you make up "accept
> all" policy, then it's difficult to build  net link between tow nodes,  you
> have to deny all other MAC addresses. If the number of nodes is more than ten,
> it's really a hard work.  As you mention, the best way is let mackiller only
> to do mac killing on certain interface.  If you think that is useful, I will
>  consider to add that in mackiller.

This is strictly a function of how dense/sparse the graph of the
emulated
network will be in terms of the number of links. In the case of very
sparse
topologies (e.g. when the number of links in the topology is closer to
N-1, as
in a linear string) the "default drop all" policy allows easier
configuration,
as you mentioned. But, in the case of denser topologies (e.g. when the
number
of links is closer to N*(N-1), as in a fully-connected mesh) then
exactly the
opposite is true, and the "default accept all" policy is easier. Two
reasons
I favor "default accept all":

  - my hunch is that true-life topologies will tend to be "relatively
    dense" as opposed to "relatively sparse" in terms of the number
    of links (or, *potential* number of links in the case of a reactive
    protocol)

  - by using "default accept all", you *don't* have to add extra code to
    check for MANET vs. non-MANET interfaces

Fred
[email-masked]