1 / 153

À la recherche des réseaux perdus. 9 décembre 2007. Le tutoriel sera donné par Jon Crowcroft,

À la recherche des réseaux perdus. 9 décembre 2007. Le tutoriel sera donné par Jon Crowcroft,. Jon Crowcroft, University of Cambridge Currently CNRS/LIP6/UPMC And Thomson Labs, Paris. Jon.Crowcroft@cl.cam.ac.uk http://www.cl.cam.ac.uk/~jac22. This talk is in English.

current
Download Presentation

À la recherche des réseaux perdus. 9 décembre 2007. Le tutoriel sera donné par Jon Crowcroft,

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. À la recherche des réseaux perdus. 9 décembre 2007. Le tutoriel sera donné par Jon Crowcroft, Jon Crowcroft, University of Cambridge Currently CNRS/LIP6/UPMC And Thomson Labs, Paris. Jon.Crowcroft@cl.cam.ac.uk http://www.cl.cam.ac.uk/~jac22

  2. This talk is in English Unfortunately (desole) my French is insufficient 1.4 Billion Indians and Chinese have chosen English (luckily we don’t have to learn mandarin or Urdu!) Even British have to learn American English for science writing We all use Greek for maths anyhow :-)

  3. There are 6 parts to this talk • Cold Topics in Networks • Reading a paper • Writing a paper • Giving a talk • Writing a proposal • Hot Topics in Networks • Acknowledgements to • Keshav • Simon Peyton Jones • Brad Karp and HT Kung • for materials used with permission.

  4. 1. Cold Topics in Networks Jon Crowcroft, Cambridge

  5. Hot v. Cold Research goes in cycles - possibly Carnot Cycles • Topics become hot • Initially, even, controversial • (active nets, social nets, etc) • Lots of people flock to the topic • Paradoxically, higher density of researchers reduces temperature • Topic goes cold.

  6. Hot Topics • Can be detected by brainstorming • Socialising and off-the-wall thinking is good • Invert a traditional approach • Stretch one dimension to an extreme • Bisociation/lateral/interdisciplinary • Tennenhouse at DARPA (Active Nets) and as head of Intel Research deliberately indulged disruptive ideas

  7. Some measures of cold topics • Number of low cited papers in low impact conferences • Fractional Performance delta in systems papers • Massive uptake of automatic tools for research (NS2, Planetlab, etc)

  8. Some examples of cold topics • [DHT and Structured P2P] • Even bad guys like the Storm Botnet use them • [Internet Coordinate Systems] • now secured too! • [Faster packet classification] • If you aren’t working with cisco, juniper or huawei? • [BGP] The Border Gateway Protocol • We even have a meta-replacement. Now is the time to deploy.

  9. More cold topics • DDoS • Define the problem - DoS on a best effort doesn’t mean much - see Newarch. • Spam • Is not largely a technical problem (see social nets and closed user groups) see ddos • Overlays • Were made up as a tool for research, not a research goal!

  10. Even more cold topics • TINA • The Intelligent Network Architecture = Knowledge Plane = network management • TCP+AQM • Mostly wrong • Multicast • 20 years without deployment? • Newarch • Not even wrong (see String Theory)

  11. Yet more cold topics • Self similarity • Surely there is a horizon effect • MANETs • 5000 protocols cannto be good • Self Organising WSNs • Unexpected behaviour may not be a plus • Small World Networks • Ask epidemiologists

  12. Now you know what I don’t like… For now :-) Your PhD topic will have been hot in Year 1. By year 3,4,5 this is unlikely to be still true - consider journals rather than conferences or workshops for later work:-).

  13. 2. How to Read a Paper Jon Crowcroft, Cambridge Based on CCR Article by Keshav (Waterloo)

  14. Stand on the Shoulders of Giants And do not stand on their toes You read other papers so that You are learning what papers are like You are current in the field You may be writing survey (literature review) You want to find what to compare with We propose a 3 pass reading approach

  15. Pass 1 • Structural overview of paper • Read abstract/title/intro • Read section headings, ignore bodies • Read conclusions • Scan references noting ones you know

  16. Pass 1 output • You can now say • Is this a system, theory or simulation paper (category defines methodology) • Check system measurement methodology • Check expressiveness/fit for purpose of formalism • Check simulation assumptions • What other papers/projects relate to this? • Are the assumptions valid? • What are the key novel contributions • Is the paper clear? • Takes about 5 minutes • 95% of reviewers will stop at pass 1 :-( • See Section 3 of this (on writing papers)

  17. Pass 2 • Check integrity of paper • Look at figures/diagrams/exes/definitions • Note unfamiliar references • Do not check proofs yet • Takes around 1 hour • You should be able to summarise the paper to someone else now • If it is unclear, you may need to pasuse overnight

  18. Pass 3 • Virtually re-implement the paper • Challenge all assumptions • Think adversarially about experiments, proofs, simulation scenarios • Takes 4-5 hours • You should be able to reconstruct paper completely now

  19. Reading batches of papers • E.g. for literature survey excercise • pick topic (hot or cold), and search on google scholar or citeseer for 10 top papers • Find shared citations and repeated author names - key papers (look at citation count/impact too) • Go to venues for these papers and look at other papers

  20. See also • Timothy Roscoe’s • Writing reviews for Systems Conferences • Writing Technical Articles • Henning Schulzrinne’s

  21. Now you can review papers… For me:) You will read 100 papers to every one you write. 90 of them will be much worse, some will be better. A few the same.

  22. 3. How to write a great research paper Simon Peyton Jones Microsoft Research, Cambridge

  23. Writing papers is a skill • Many papers are badly written • Good writing is a skill you can learn • It’s a skill that is worth learning: • You will get more brownie points (more papers accepted etc) • Your ideas will have more impact • You will have better ideas Increasing importance

  24. Writing papers: model 1 Idea Do research Write paper

  25. Writing papers: model 2 Idea Do research Write paper • Forces us to be clear, focused • Crystallises what we don’t understand • Opens the way to dialogue with others: reality check, critique, and collaboration Idea Write paper Do research

  26. Do not be intimidated Fallacy You need to have a fantastic idea before you can write a paper. (Everyone else seems to.) Write a paper, and give a talk, about any idea, no matter how weedy and insignificant it may seem to you

  27. Do not be intimidated Write a paper, and give a talk, about any idea, no matter how insignificant it may seem to you • Writing the paper is how you develop the idea in the first place • It usually turns out to be more interesting and challenging that it seemed at first

  28. The purpose of your paper

  29. Why bother? Good papers and talks are a fundamental part of research excellence Fallacy we write papers and give talks mainly to impress others, gain recognition, and get promoted

  30. Papers communicate ideas • Your goal: to infect the mind of your reader with your idea, like a virus • Papers are far more durable than programs (think Mozart) The greatest ideas are (literally) worthless if you keep them to yourself

  31. The Idea Idea A re-usable insight, useful to the reader • Figure out what your idea is • Make certain that the reader is in no doubt what the idea is. Be 100% explicit: • “The main idea of this paper is....” • “In this section we present the main contributions of the paper.” • Many papers contain good ideas, but do not distil what they are.

  32. One ping • Your paper should have just one “ping”: one clear, sharp idea • Read your paper again: can you hear the “ping”? • You may not know exactly what the ping is when you start writing; but you must know when you finish • If you have lots of ideas, write lots of papers Thanks to Joe Touch for “one ping”

  33. The purpose of your paper is not... To describe the WizWoz system Your reader does not have a WizWoz She is primarily interested in re-usable brain-stuff, not executable artefacts

  34. Examples of WizWoz • Crash Proof OS for Mobile Phones (singularity in F# on an iPhone) • Go Faster VM (Xen) • Nimrod

  35. Your narrative flow I wish I knew how to solve that! • Here is a problem • It’s an interesting problem • It’s an unsolved problem • Here is my idea • My idea works (details, data) • Here’s how my idea compares to other people’s approaches I see how that works. Ingenious!

  36. Structure (conference paper) • Title (1000 readers) • Abstract (4 sentences, 100 readers) • Introduction (1 page, 100 readers) • The problem (1 page, 10 readers) • My idea (2 pages, 10 readers) • The details (5 pages, 3 readers) • Related work (1-2 pages, 10 readers) • Conclusions and further work (0.5 pages) • See section 2 (on reading!)

  37. The abstract • I usually write the abstract last • Used by program committee members to decide which papers to read • Four sentences [Kent Beck] • State the problem • Say why it’s an interesting problem • Say what your solution achieves • Say what follows from your solution

  38. Example • Many papers are badly written and hard to understand • This is a pity, because their good ideas may go unappreciated • Following simple guidelines can dramatically improve the quality of your papers • Your work will be used more, and the feedback you get from others will in turn improve your research

  39. Structure • Abstract (4 sentences) • Introduction (1 page) • The problem (1 page) • My idea (2 pages) • The details (5 pages) • Related work (1-2 pages) • Conclusions and further work (0.5 pages)

  40. The introduction (1 page) • Describe the problem • State your contributions ...and that is all ONE PAGE!

  41. Describe the problem Use an example to introduce the problem

  42. e.g. of systems problem • Mobile Phones crash a lot • Wireless media is vulnerable • Bad software on mobile phone can hurt user (cost money, time, pain) • Bad software on radio can hurt all users • We have a lot better tools to write safer software and have done so on desktops and servers • Can they work on small devices with limited resources, and if so, how well?

  43. State your contributions • Write the list of contributions first • The list of contributions drives the entire paper: the paper substantiates the claims you have made • Reader thinks “gosh, if they can really deliver this, that’s be exciting; I’d better read on”

  44. State your contributions Bulleted list of contributions Do not leave the reader to guess what your contributions are!

  45. E.g. of systems contributions • We encapsulate all the modules of software on a cell phone in F# behavioural description wrappers, and • Run a model checker on them (e.g. isobel) • And then try various well known attacks that fail on desk top but succeed on windows mobile and symbian phones • We then show our software is also smaller and faster….

  46. Contributions should be refutable

  47. No “rest of this paper is...” • Not: • Instead, use forward references from the narrative in the introduction. The introduction (including the contributions) should survey the whole paper, and therefore forward reference every important part. “The rest of this paper is structured as follows. Section 2 introduces the problem. Section 3 ... Finally, Section 8 concludes”.

  48. Structure • Abstract (4 sentences) • Introduction (1 page) • Related work • The problem (1 page) • My idea (2 pages) • The details (5 pages) • Related work (1-2 pages) • Conclusions and further work (0.5 pages)

  49. No related work yet! Related work Your reader Your idea We adopt the notion of transaction from Brown [1], as modified for distributed systems by White [2], using the four-phase interpolation algorithm of Green [3]. Our work differs from White in our advanced revocation protocol, which deals with the case of priority inversion as described by Yellow [4].

  50. No related work yet I feel stupid • Problem 1: the reader knows nothing about the problem yet; so your (carefully trimmed) description of various technical tradeoffs is absolutely incomprehensible • Problem 2: describing alternative approaches gets between the reader and your idea I feel tired

More Related