Network Science Articles

I will be doing a brief literature survey on Network Science. This post is meant to track the things I plan to read.

Emerging Areas

1. Social networks (Sep 2010, IEEE Networks), NetSciCom 2009, 2010, 2011 (INFOCOM Workshops)
2. Social network analysis for ad hoc networks, and the Internet (IEEE Networks, Nov/Dec 2010)
1. IEEE Networks article, Dimokis (Aristotle), Tussilias (Thessaly), references therein
2. Centrality measures for network design and control: Alberto Leon-Garcia (Toronto), 
3. Internet: On power law relationships of Internet topology, Faloustos (CMU)
3. Power grid networks: mostly about vulnerability, survivability, robustness
1. Robust network design, Alberto Leon-Garcia (Toronto)
4. Biological networks (Vespignani's book) 
5. Biologically inspired networks: self-organizing and self-managing networks (May 2010 special issue, IEEE Networks)
1. Sensor networks: Shuguang Cui (Texas A&M), H.T. Kung (Harvard)
2. Cognitive: Helen Tang (Defence R&D Canada)
3. IP Networks: Nazim Agoulmine (Univ. Ervy)
6. Internet: topology analysis, traffic modeling and routing - many references
1. Internet Topology discovery: Timur Friedman (UPMC, France), Ariel Orda, Technion
2. Collaborative monitoring: Nadav Aharony (MIT)
3. Topology analysis: Amid Vahdat (UCSD)
4. Traffic modeling and routing: Deniz Zeuv (Oxford)
7. Transportation networks: Pravin Varaiya (UCB)

Katy Börner, Soma Sanyal and Alessandro Vespignani (2007) Network Science
Processes involved in studying network science

1. Network sampling: acquiring the network structure, typically incomplete, biased
2. Measurement: node and edge properties, clusters, distributions, network types
3. Modeling and Validation: generating random graphs
4. Modeling dynamics: epidemics, stability
5. Visualization: layouts

Internet: 1,2,5
Social networks: 3
Power networks: 2,4

Also interesting: Eric Kolaczyk, Statistical Analysis of Network Data
Five broad areas
1. Network mapping (finding out which nodes to connect, visualizing the resulting graph)
2. Characterization (analyzing centrality, community structure etc)
3. Sampling and Modeling (estimating network size/totals by sampling)
4. Inference (topology inference, link prediction etc.)
5. Processes (static/dynamic random variables - analyze with MRF/regression)

Related workshops

1. SAMSI workshop on Complex Networks
2. MITACS Intl. Focus Period: Advances in Network Analysis & Applications

Review Time-Frame

Do you always submit the reviews assigned to you on time? Putting it in a different way, do you even begin reading them a few days before the due deadline?

Lets restrict the discussion to journals like IEEE Trans. Signal Proc., which have a short but elastic time-frame for submission of reviews. Conferences and special-issue journals (e.g., JSAC) of course, have inelastic time-frames, so one has no choice but to stick to the deadline. While this always leads to timely reviews, the review quality may suffer. I've had my share of one-line reviews; ``The paper is good and a nice decodability criterion is established.''

From my brief stint at reviewing and submitting my own papers, I guess most graduate students would answer the above questions in negative. Some students, who tend to get several review requests, first look at the paper on the due date after emailing the associate editor for an extension. They usually get a two-week extension, which sometimes expands into two months - not funny when one is on the receiving end.

The truth is, graduate students do not always have spread-out research interests and often get assigned papers that are not exactly in their area. Mix in some procrastination and you have a delayed and lousy review. On the other extreme, students sometime get papers in their exact area as well. Reading the paper is then a delight, and the reviews mostly get done on time.

So how does one optimize one's timeliness ? Perhaps one could use waterfilling. That is, if the paper is outside one's area, realize that the review is going to be bad and get done with it, as soon as possible. The AE may not be impressed by the review but will at least get it on time, and may even decide to spend some time on the paper himself. On the other hand, if the paper is aligned with one's research interests, spend some time writing the review, even if it requires asking for an extension. The review should be extra long if it is a rejection; the authors should gain something out the process.

Plagiarism at IITK

There has been a serious accusation of plagiarism at the biotech dept at IITK. As if this was not bad enough, stories of several similar cases have surfaced from all other IITs. Of course, the Indian media has done its part headlining the graveness of the situation.

For an institute that claims to maintain the highest of the standards, even one such incident is unforgivable. In retrospect however, I think such an incident was bound to happen, sooner or later. When I was a student at IITK, I do not recall reading any emails from DOAA underlining the seriousness of scientific misconduct.

If I am allowed to guess, the students who copied from Wikipedia are not the back-stabbing villains portrayed by the media. Most probably, they were simply unaware of the fact that such blatant plagiarism is easy to spot and would cost them their careers. It is partly their adviser's fault for not predicting it and it is going to cost him his career too. Most of all however, it is the institute's fault for not sensitizing the faculty and students of the issue, especially in the backdrop of other recent cases in academia; see e.g., Hwang Woo-suk case in biology.

All in all, it was a jolt that the institute needed. The brand reputation has suffered but I am sure that we will emerge stronger from the ordeal.

Lab TAing

One of my colleague just got a TA ship and is in charge of teaching the electronics lab. Since I had TAed this lab previously, she approached me for any tips or tricks I had to offer. As I am always too eager to dole out advices, we had a good twenty-minute discussion on what one ought and ought-not to do. The gist of my advice was that role of the TA was to assist the students do the experiments without resorting to any kind of spoon-feeding. Towards this end, I would stress the importance of the following.

1. Do the experiment in advance, even if it is piece of cake. Performing the experiment yourself makes potential problems surface when there would seem to be none. Some of them may be really trivial, e.g., an experiment setup may be such that it may require three probes per person, and you may need to get extra probes beforehand. If the experiment is complicated, you could also jot down the possible mistakes students are going to make.

2. Ask the students to start doing the experiment as soon as they arrive, without waiting for the TA. The students should also be encouraged to skip a problem if they are struck if the TA is not available or busy somewhere. These practices help control congestion especially if you have a large class and for particularly difficult experiments.

3. Never tell the solution, always drop progressively easier hints. Not only will this make the students think harder but also make them smarter, taking some load off the TA's shoulders for future experiments. You could try to give the students some pointers in the beginning but the best practice is to let them figure out everything by themselves. However you must be available for hinting whenever they are struck.

4. Visit each student periodically, see what numerical values they obtained and whether they are in the ballpark. Encourage students to doubt their solutions and "feel" the circuit. The ability to approximately solve circuits is extremely important. When a student shows you his value, think aloud on how you would confirm that the value is approximately correct. Encourage the students to emulate this reasoning style.

5. Encourage proper report writing skills. Depending on the instructor/course, one may or may not have to submit lab reports and those require specific guidelines to be handed out. But the process of jotting down observed values in the lab is also important. Encourage students to write down everything, including what may have went wrong.

6. Drop examples of real-life applications where the said circuits are being used. It takes away the monotony of lab work.

7. Lab exams are the easy part (at least for the TA). These are days when you can relax while the students toil.

Apart from these, I also follow the philosophy that for the time a person is my student, "their business is my business." In particular, I remember a related incident where a co-TA's best student did not show up at the final exam. While discussing the grading policy later, I was surprised to learn from him that he did not even send an email inquiring his student about what had happened as "it was none of his business". I disagree with this ideology but do understand that it may be something cultural.

Proposal Reviews

I recently got an opportunity to review a couple of NSF proposals my professor gave me. Interestingly, one of the proposal was excellent while the other one was mediocre. I thus learned a lot comparing their writing styles.

For those new to the dojo, most state, army and private funding is procured by submitting proposals to the corresponding agencies which are mostly peer-reviewed. The intent of the proposal is to pose research problems, solving which would significantly advance the state of the art. These problems must somehow be related to the authors past work, thereby establishing his/her credibility. In the end, not all problems need to be solved. The idea instead is to establish concrete directions of future research that are promising not only for the author but for the entire community.

While I am no authority on proposal writing, I could point out some "common mistakes" I have noticed thus far.

1. Wish-list: The proposal should not sound like the future-work sections of conference papers. One cannot simply say that NP-hard problems will be investigated without explicating the exact approach. In fact each proposed problem must be devoted a couple of paragraphs at least: one formulating the problem and another giving an insight into the proposed solution methodology and possible challenges.
2. Text-only: Mathematics is a language. Use of equations helps express problems clearly. While it is necessary to keep the description at a higher level, one or two equations per-page is not scary at all.
3. Secret-designs: It is possible for a reviewer to pick up the proposed solution and start working on it. However, proposals which entice reviewers into taking up the problems are always considered the best and always get accepted. Its a risk that has to be taken.
4. Jargon-master: Peer reviewed proposals do not need to use DARPA-like jargon except probably beyond the summary. Buzzwords like cyber-infrastructure should not be used in a proposal that investigates routing protocols.
5. Can-be-generalized: The usefulness of running examples cannot be stressed more. However, generalizing toy-examples is often easier said than done. I have seen at least two proposals that described their approach on toy examples and left the problems at that stage.

TAing at IITK

My first ever stint as a TA was during my fifth year at IIT Kanpur. Since IITK has a good number of graduate students, the overall load was light. For most part of the semester, my job simply involved LaTeXing assignments and solutions, getting photocopies, and putting up solutions on the notice board.

The assignments were handed out on a weekly basis, and both text and figures involved math symbols (it was a communications course). Since I had a limited knowledge of LaTeX and related drawing tools, I ended up spending a lot of time drawing the figures.

At times when the instructor was absent, I was also called upon to take some of the tutorial sessions. These sessions involved explaining solutions to one or more of the problems in case people were struck. Since I already had the solutions, the task was not challenging in any way. Indeed, after I had taken a couple of sessions, I wondered how some of my own past tutorial instructors had managed to do such a bad job.

The instructor of the class was Prof. AK Chaturvedi. Perhaps the most beneficial aspect of that TAship was the opportunity to observe one of the best teachers in the EE department up close. I specifically remember admiring his attention to detail. For instance, I was often careless and made typos in almost all the assignments and solutions. Needless to say, he used to catch all the typos - every time. He also made significant efforts trying to be available in his office before quizzes and exams and often organized extra office hours inviting students to clear their doubts.

Finally, the most boring part was having to stand in the lecture hall while the students wrote their exams. But I suppose it would be boring even if I were to become a professor.

Student Feedback Forms

Its judgment day and the anonymous student feedback forms have finally arrived. I contended that they were probably filled halfheartedly. It was the last day of classes and everyone had something better to do. But I did hope that they would at least provide me some feedback on my teaching style.

Unfortunately however, there weren't many long comments. Most of the responses to "What did the instructor do that most helped your learning?" were "Helped me when I got struck" or "Explained the problem well." Fortunately, the response to "Additional Comments" was always "Very good TA" or "Best TA ever." I am satisfied but (a little) sorry that I will probably not be TAing again - I have an RA now.

Of the lighter side, there were some interesting comments as well. The following was a response to "What did the instructor do to help..."

"Was able to look at the circuit and instantaneously tell the problem."

In reality, I have always sucked at circuits. This was the reason why I kept away from circuits courses in my undergrad and chose communication. In the lab though, every one is doing the same experiment and makes similar mistakes. Since I was always skirting around the lab trying to see where people got struck, I was always up-to-date with the common mistakes of the session. From a student's perspective though, it would have appeared instantaneous. Too bad the speed of light is finite.

The following was a response to "Additional Comments"

"I wanna be the very best
Like no one ever was
To catch them is my real test
To train them is my cause..."

I was stumped when I first saw these lines. Who is this guy trying to catch ? A little search revealed that the lines are from Pokeman (the anime) and the only thing he is trying to catch is his breath from running animarathons. Ironically, his response to the number of course hours spent was 0-2: pretty low for someone who wants to be the "very best."