Seminars and MTPs

Topics and Projects

• Seminars and MTP Jan 2015-June 2016. This spreadsheet holds the status of MTP projects for the 2014-2016 batch of students.
• Seminars and MTP Jan 2016-June 2017. This spreadsheet holds the status of MTP projects for the 2015-2017 batch of students.
• Here is a list of seminar topics offered in Spring 2016.
• Here is a list of seminar topics offered in Spring 2017.

Meeting schedule: Autumn 2016

• Current MTech2 students: Tue/Fri afternoons in CH.

Guidelines for Seminars

Weekly meetings

• We will meet once a week (for half hour or so) to discuss a paper. You are expected to read one paper per week, though some difficult papers may spill over to the next week. Overall, your seminar is supposed to cover 8-9 good papers.
• When you read papers for the semester, focus not just on the details of the paper, but on the overall "big picture", and on how the paper fits in with other papers in this topic. For example, after reading the paper, you should be comfortable answering the following questions:
  1. Problem definition.What is the problem being solved by the paper? And why is the problem important / relevant?
  2. Context. How does this paper improve upon existing work? Why is this paper needed when other ideas exist? What does this paper claim to do that other papers don't? (This point will become clearer as you read more papers.)
  3. Key Idea.What is the main insight / key idea of the paper? Often, it is okay to ignore the details in the first reading - you should try to get a high level understanding of the idea first before you dig into the details.
  4. Validation.How do the authors validate their idea? What experiments / simulations do they do? Is it enough? Are you convinced the idea works?
  5. Relationship with your project.How is this paper related to your proposed research topic? Are you solving the same problem? A related but complementary problem? A completely different problem? It is good to understand how this paper fits in with your work.
• You may find this tutorial on how to read a paper helpful. When reading a paper, try to understand the big picture before you dive into the details. For a first read, the details are less important, and the overall context and high-level understanding is more important. That is not to say that you shouldn’t read the details (you must), but don’t get lost in the details before you understand the big picture.
• I recommend preparing a short presentation for every meeting, of not more than 10-12 slides. You can organize your presentation along the 5 main points above (or in any other way). Below are some tips for preparing your weekly presentations.
  1. Please take your weekly presentations seriously, and prepare good quality slides. I expect you to reuse these slides for your final seminar presentation.
  2. You do not have to explain every single idea, every single graph, and every single sentence in the paper. Suffices to explain the key idea(s) of the paper in your own words, and at a high-level, to convince me (and your examiner, eventually) that you have actually understood the paper. Your understanding will be seen in how well you can identify the main parts of the paper, and summarize them in your own words, in a concise fashion. Stick to the limit of 10-12 slides. Do not repeat/reproduce what's in the paper without understanding it.
  3. Come up with running examples that illustrate the ideas in the paper. You can even use the same example across multiple papers, to illustrate how a particular problem is solved by various papers. Coming up with your own examples will convey a certain level of understanding.
  4. Draw figures, use animations etc to explain concepts. Avoid long blurbs of text.
  5. Do NOT copy complicated equations, pseudocode and other such things straight from the paper. It will be very difficult to explain and understand. Instead, explain such content in your own words.
  6. If there are any flaws in the paper, you should be able to point them out. Think critically about the paper, and do not take everything that's in the paper as gospel. After the first few papers, you should develop a taste for what is a good idea and what is not.
• Bring your laptops or email me the presentation beforehand so that we can view it on my computer.

Seminar report and presentation

• You will be required to submit a final report and make a presentation to an examiner to get graded in your seminar.
• Have a first draft of your seminar report at least two weeks before your presentation date, so that I can review and give feedback. Show me a draft of your presentation at least one week before your presentation day. You must get feedback on your talk from me, and from at least one other classmate of yours (preferably from someone in the same area of systems/networking, but NOT working on the exact same topic as you.) Two mock presentations, one to me, and one to your peer, are a must.
• Your seminar report should be no more than 20 pages. It should roughly have the following structure.
  1. Introduction (1-2 pages): describe the broad problem that your set of papers are trying to solve. Why is this an important problem? Use an example if needed to motivate the problem area and the main solution techniques. Do not just list all the papers you have read; instead, you must provide a taxonomy of the papers / solution techniques you have studied. That is, you must be able to classify the papers you have read into some broad bins based on some criteria, and describe this broad classification in the introduction. This high level understanding of the problem and solution space is the most important contribution you can show from your seminar. At the end of the introduction, the reader should have a decent idea of the problem statement, and the high level classes of solutions to the problem.
  2. You may have an optional background section that provides more details and terminology to understand the rest of the report.
  3. Survey of papers read (5-6 pages). Briefly describe (in half page or so each) the key idea behind each of the papers you have read, along with a citation to the paper as appropriate. Describe the key idea of the paper in your own words / figures. Comment critically on the paper (merits / flaws etc). You must organize these papers according to the broad classes you have come up with in the introduction.
  4. Compare and contrast the solutions (1-2 pages): how do the various approaches described above compare with each other? Which is applicable in what scenarios? What are the pros and cons of each? Ideally you should have a table or some such concise summary of all papers. Or you can use one example and see how various systems handle it. How you compare is left to you - this is another place where your contribution / understanding will show.
  5. Conclude with describing how this seminar will lead into possible topics for your MTP. Most of you should have a fairly good idea of your MTP topic by the time your seminar is done.
• Your presentation should also be structured along similar lines. You should prepare 18-20 slides for a 20 minute presentation, leaving 5-10 minutes for Q&A. Please keep the following in mind for the presentation.
  1. Keep your audience in mind when you give the talk. For the seminar, you should assume that your examiner (and other students who come to attend) knows the basics of the field, but not any details. Make your seminar self contained, so that anyone who has done a CS641 type course should be able to follow. You cannot speak the way you speak to me at our weekly meetings, assuming all background knowledge.
  2. Start your seminar with an overview of the problem, the solution techniques, the context, and why it is important to solve the problem. Define all terms you will use. Spend about 4-5 mins easing the audience into your presentation. Do not start with a paper on slide 1 and expect people to follow along.
  3. After the introduction, you may start talking about each paper. Keep the discussion simple and accessible. Use examples and figures. Concrete examples that illustrate your problem and solution are a thousand times better than an abstract explanation. Keep yourself in the shoes of the poor audience who is trying to grasp several months of your work in 30 minutes.
  4. Spend the last few minutes summarizing all papers, pros and cons, comparisons, take-away points etc. If you feel you are running out of time, skip some intermediate papers but do not skip this part.
  5. Prepare for no more than 20 minutes of talking time. It will end up being 30 minutes with questions. A rough guideline is about 20 slides for a 20 minute talk, but no more.
  6. Make your slides interesting with figures, colors etc. where appropriate.
  7. Finally, please take your presentations seriously. The goal of the seminar is not just doing a literature survey for your thesis. A primary goal is to teach you how to read papers, identify the crux of the paper, and present it in simple terms to a general audience. It is not enough if you are technically sound (though it helps a long way), you should also be able to take people along with you and convince them of your technical capabilities. I cannot stress enough the importance of good communication: prepare seriously for your talks (this one, your MTP presentations, and so on).
  8. And attend a few other seminars, not just your own, so you know what works and what doesn't.

Optional R&D project

If you end up doing an R&D project, we will setup weekly meetings, roughly aligned with your seminar slot. You can also drop by the lab and meet me with the senior students. Finally, you will have to submit a report at the end of the semester, and do a small demo of what you have learned.

Guidelines for MTP

During the semester

• We will aim to meet twice a week during the semester for regular updates. However, if you are stuck on something, please don't wait for the next meeting slot, and approach me earlier.
• You should have a clear idea of the deliverable expected by the end of the semester fairly early (within the first month of starting your stage I or stage II).
• You are expected to put in 30-40 hours a week on an average. Maintain a consistent pace throughout the semester, so that work never stalls.
• Work in the lab as far as possible. Coming to the lab regularly everyday will help you focus better. Further, the projects of several students are closely related, and working together can boost your productivity.
• Flag any requirements for equipment, or any other needs / concerns you have to me, so that I can act on them in time.

MTP Stage I/II report and presentation

• Keep your reports to around 20 pages for stage I and 30 pages for stage II. Plan a 30 minute presentation (20 min + Q&A) for your stage I, and 45 minutes (30 min + Q&A) for your stage II.
• Start working on an outline of your report one month before your presentation. I expect to receive a draft about 3 weeks before, and we can iterate over it in parallel with your work. And you should have a final report one week before your presentation. Treat this as a hard deadline.
• Similarly, I expect to see the first draft of your presentation two weeks before your MTP presentation. In the week before your presentation, you must do at least two mock presentations , one to me, and one to your peer (someone in this general broad area, but not working on the same topic).
• Have clarity on what your problem statement is, and pick a suitable suggestive title for your thesis.
• Both your report and presentation should start out with a short introduction / overview section. You should give a high-level background and motivation, an overview of the problem you have solved, the work you have done (in seminar, R&D, stage I, stage II etc.), and your main result and contributions. You should get through this content within the first 1-2 pages of your report, and within the first 5-6 slides of your presentation (in under 5 minutes). So, anyone reading your report or attending your talk should get a good idea of the nature/quantity/quality of your work, and your key idea / contribution (obviously, not all the details) in under 5 minutes.
• Next, you can have a section of more related work / background to clarify the context for your problem. You may devote more space to it in the report, but during the presentation, talk about only what is absolutely required to understand the rest of your talk.
• Next, you will describe your design and implementation in detail, followed by your experiments and evaluation. Use figures, tables, flow charts etc. liberally to explain your ideas, instead of long blurbs of text.
• You should have a small number of well-explained graphs in your evaluation, instead of a large number of results. For each graph, you must carefully explain what the experimental scenario is, what the X and Y axes are in the graph, what the graph/result means, and what conclusions to draw. Graphs should be easily readable on paper, and visible when projected on screen.
• You must conclude by pointing out your major results and conclusions.

Grading

1. Your actual work, both quantity and quality. Ideally, you should have completed enough work to meet the goal set out at the start of the semester.
2. Your initiative / independence in doing things on your own (without me pushing you or having to tell you every single thing), and your enthusiasm and sincerity during your project.
3. Your ability to communicate well in your report and presentation.

• AA: You have done exceedingly well on all three aspects above.
• AB: You have done very well in most aspects, but missed on a few things (e.g., work was good but presentation wasn't great, or didn't show enough intiative on your own and needed lot of hand-holding).
• BB: Decent effort, average output, needs improvement in most aspects.
• BC: Below average work and effort.
• CC: Bad quality of work, did not learn much or accomplish much in the project.