CS211: Protocol and Systems Design for Wireless and Mobile Networks

1. CS211: Protocol and Systems Design for Wireless and Mobile Networks Instructor: Songwu Lu slu@cs.ucla.edu Office: 4531D BH Lectures: 2:00-3:50am M&W office hours: 4:00-5:00pm M&W

2. What this course is about... • Introduce • Internet design philosophy • Wireless networking protocols • Mobile computing system software design • Trendy topics • System programming skills • How to start research

3. A picture of the course coverage Networking fundamentals: Internet philosophy and principles • Wireless Protocols • MAC protocol • 802.11 Standard • - Scheduling • - Mobility management, ad-hoc routing • - wireless TCP • Mobile Computing • - middleware, OS, file sys. • services, applications • Topical Studies • -Wireless security • Sensor networks • -QoS and Energy-efficient design • -Mesh Networks • -MIMO Systems

4. Emerging Wireless Networks Internet Backbone Base Station Fixed Host Mobile Host Wireless Cell

5. Growth of Wireless Users

6. The Wi-Fi Space • It is one of the fastest growing industry sectors • 100,000 public hotspots by 2005 • Most notebooks will have embedded wi-fi card • Go and check the local hotspots online • www.ezgoal.com/hotspots/

7. Protocol Stack • Wireless Web, Location Services, etc. • Content adaptation, Consistency, File system • Wireless TCP • Mobility, Routing • QoS • Scheduling • MAC Application Layer Middleware and OS Transport Layer Network Layer Link Layer & Below

8. The Course Description • No required textbook for this course, only a set of papers • Read and discuss • your class participation counts • practice what you have learned • get your hand dirty: do a term project • make your contributions • Heavy workload expected • You are expected to be prepared for each lecture by reading the paper BEFORE coming to the lecture

9. Prerequisites • basic knowledge of packet switched networks & familiarity with TCP/IP protocol suite • adequate programming experience • familiar with C/C++/UNIX • useful reference books: • “Internetworking with TCP/IP, Vol’s I, II, III” by Doug Comer • “TCP/IP Illustrated, Vol’s 1 & 2” by Stevens

10. Course Workload • One midterm, no final exam • Midterm: November 10th, in class. • reading assignment: • 1~2-page summary for the assigned reading of each lecture • 3 strong points, 3 weak points, suggestions • Similar to the paper review process you are going to do for your field in the future • all assignments due 12:00pm(noon) before lecture on the due date • email to slu@cs.ucla.edu with subject “cs211: homework #”

11. Course Project • A few big projects • Several topics within each big project to be distributed this Wednesday • 2-3 persons on each topic • Pick a topic and a team by next Monday • Proposal + Checkpoint + Presentation + Final Report

12. Why such projects? • Interact closely within your topic team • Discuss every three weeks within your big project to have the big picture in mind • Stimulate discussions across teams • Most topics are well defined, and you have a good starting point

13. Grading Policy Grading breakdown: • in-class presentation: 10% • 5~10 min each person • Will get an assigned paper (expanding the topic scope of the paper discussed in class) from me • midterm exam: 30% • homework assignments: 20% • There would be 19 assignments, you are expected to turn in at least 15 • The 15 critiques with highest scores to be counted • term project: 40% • proposal 5%, checkpoint 10%, final report 15%, presentation & demo 10%

14. Course policies • Homeworks, project proposals & reports all due 12:00pm on the due date • No late turn-in accepted for credit!!! • No makeup exam!!! Course homepage: http://www.cs.ucla.edu/classes/fall03/cs211/ cs219@cs.ucla.edu

15. Tips on Doing Research in Graduate School • How to do productive research in graduate school • What are the bad practices you should avoid • Your feedback?

16. The content of this presentation • We take slides and points from many outstanding researchers: Dave Patterson, Richard Hamming, Craig Patridge, Nitin Vaidya, and the many references and sources cited there. They deserve all the credits • I also share some of my own experiences • We need your input and feedback too

17. Caveats • Only opinions from some people. Others may not agree, including your advisors. • Use advice at your own risk • I do not necessarily follow the advice all the time • This presentation may not follow some rules it talks about

18. What is Research, Anyway? • Research is not really about coming up with a nice solution to a hard (possibly new) problem, to show how smart you are. • It is a process: • identifying a research problem • Coming up with a nice/new result (including simulating, implementing, testing your solution) • Writing your results well • Presenting your results • Marketing your work • Engineering is not science, it is about different tradeoff (whether u can do things easier, efficient, more convenient, … at acceptable cost/complexity), precisely true/false is not the main concern

19. A Few EQ Rules • Motivation: “you are indeed interested in PhD research” • Think carefully about your career goal when you start your PhD • NOT: “My family asks me to get a PhD…”, “It is hard to find a job with a MS degree now…”, “I want to hang around in school a little longer…” • We can get you interested in something for some time, but not all the time • Good start: “well begun, half done” • Work harder during the first two years to settle down in research • Have a taste of what is good research; not poisoned by the bad taste • Believe yourself: your mindset has not be “framed” by conventional approaches yet; you can be innovative since you do not know much • You have more energy and can have less distraction at this time • Take the initiative: “you do care about what you are working on” • Do not be afraid to talk to your advisor or others, and let people know the negative results/setbacks etc. • “If u do not talk to these folks, who can u talk to???” • disconnected communication causes more confusion among people • Be honest to research and yourself; do not hide the nasty findings. If you do not understand something, ask; then you will know it. • The reality of “capture effect”: Each advisor has more students than (s)he can handle; whoever is more aggressive gets more feedback more output • Push for the project schedule from your side: call for meetings, set deadlines for internal drafts, look for places where to publish, etc.

20. EQ Rules (Cont’d) • Regular life: “manage your time and life properly” • Shift from “deadline scheduling” to “priority scheduling” • Evaluate your progress periodically. No one else will tell you that you are not efficient • Have a “to-do” list on a daily/weekly/monthly basis • Keep your most productive time-slot during a day to yourself • No interruption even by your advisor, full concentration • Even when the deadline comes

21. How to put yourself into the best position? • Keep yourself informed and networked: “know what is going on and talk to people” • Know the literature on the topic you are working on; not let us tell you what to read. A quick rule “10+10” for breadth and depth: ten top systems/network conferences and ten leading groups • People networking: the best way to be a missionary for your work • Conference is a best place to talk to people. “Do not spend most time to polish your slides/talk there!!” • When people contact you for your work, be responsive. “If you do not care about your work, who should care?” • Attend seminars: people present the “meat” and “dark side” of their work in a talk • Balance between quality and quantity: “make your record without controversy” • Target a top conference each year: show your work quality • Try at least a couple of small conferences: show your productivity • Good way to practice writing, independent research, presentation,… • A nice way to go to scenery places for sightseeing, vacations…

22. Selecting a Problem • Solve a real problem that sb. cares about • Follow the industry technology trend and try to stay ahead of it a little • Bad move: even if technology appears to leave you behind, stand by your problem • Bad move: avoid payoffs of less than 20 years • Working on a new problem is always easier • People have worked on some problems, e.g., congestion control, for years. It is debatably harder for you to jump in and make major contributions • Select a topic that you are interested for some extended period of time, not just for a month • Interdisciplinary topics are always better, they can be very fruitful • Running real experiments to discover new problems • For systems topic, start from yourself: what do you need the systems to do for you?

23. Coming up with a solution • Do not rush for a solution simply based on the literature or what others tell you • Understand the problem better, the solution naturally follows • Use common sense • Do not try to simply combine several existing solutions • Explore new approaches: the alternative/opposite first • Ask questions based on your intuition • Keep things simple unless a very good reason not to • – Pick innovation points carefully • Best results are obvious in retrospect“Anyone could have thought of that” • Complexity cost is in longer design, construction, test, and debug • Fast changing field + delays => less impressive results • Bad move: best compliment: it is so complicated, I cannot understand the ideas • Best solutions are a combination of simplicity and depth • Keep the solution core simple • Depth is on second-level issues and fixes • A relevant issue: How do I know mine is different from others • READING PAPERS

24. How to read a paper? • Know why you want to read the paper • To know what’s going on • title, authors, abstract • Track a few leading groups/researchers in your area, typically less than 10 is enough • Only a few conferences (and journals): sigcomm, mobicom, infocom, sosp, sigmetrics, mobisys, … • Papers in your broad research area • introduction, motivation, solution description, summary, conclusions • sometimes reading more details useful, but not always • Papers that are directly relevant to your work • read entire paper carefully, and several times

25. What to note • Authors and research group • Need to know where to look for a paper on particular topic • Theme of the solution • Should be able to go back to the paper if you need more info • Approach to performance evaluation • Note any shortcomings • Be critical. It is easy to say nice words about a work, it is harder to identify limitations/flaws

26. In the process of a research project • Get Periodic Reviews/Feedbacks with Others • Talk to people and ask what they think • Give a seminar within your group periodically to collect feedback • Explain the results to your friends, see whether they can grasp your problem and your solution • For both technical people and non-technical people • Exchange emails, publish technical reports

27. Evaluate Quantitatively • If you can’t be proven wrong, then you can’t prove you’re right • Report in sufficient detail for others to reproduce results • can’t convince others if they can’t get same results • For better or for worse, benchmarks shape a field • Good ones accelerate progress • good target for development • Bad benchmarks hurt progress • help real users v. help sales? • Before you run real experiments, do an intuitive analysis • Math does not need to be fancy, as long as it proves the point; in fact, best theory starts from scratch, not from some complex theorem you never heard about

28. Marketing • Publishing papers is not equivalent to marketing • Missionary work: “Sermons” first, then they read papers • Selecting problem is key: “Real stuff” • Ideally, more interest as time passes • Change minds with believable results • Dave Patterson’s experience: industry is reluctant to embrace change • Howard Aiken, circa 1950: • “The problem in this business isn’t to keep people from stealing your ideas; its making them steal your ideas!” • Need 1 bold company (often not no. 1) to take chance and be successful • RISC with Sun, RAID with (Compaq, EMC, …) • Then rest of industry must follow • Publicize software: when people use your tools, they know your results • think about how ns-2 and its wireless extension evolve

29. How to write a paper • Do unto others as you would have them do unto you • When you have truly exceptional results • P == NP • Probably doesn’t matter how you write, people will read it anyway • Most papers are not that exceptional • Good writing makes significant difference • Better to say little clearly, than saying too much unclearly

30. Readability a must • If the paper is not readable, author has not given writing sufficient thought • Two kinds of referees • If I cannot understand the paper, it is the writer’s fault • If I cannot understand the paper, I cannot reject it • Don’t take chances. Write the paper well. • Badly written papers typically do not get read

31. Do not irritate the reader • Define notation before use • No one is impressed anymore by Greek symbols • If you use much notation, make it easy to find • summarize most notation in one place • Avoid Using Too Many Acronyms • AUTMA ?! • You may know the acronyms well. Do not assume that the reader does (or cares to)

32. Writing a draft • First read Strunk and White, then follow these steps; • 1. 1-page paper outline, with tentative page budget/section • 2. Paragraph map • 1 topic phrase/sentence per paragraph, handdrawn • figures w. captions • 3. (Re)Write draft • Long captions/figure can contain details ~ Scientific American • Uses Tables to contain facts that make dreary prose • 4. Read aloud, spell check & grammar check (MS Word; Under Tools, select Grammar, select Options, select “technical” for writing style vs. “standard”; select Settings and select) • 5. Get feedback from friends and critics on draft; go to 3. • www.cs.berkeley.edu/~pattrsn/talks/writingtips.html

33. How to write a systems paper • Provide sufficient information to allow people to reproduce your results • people may want to reproduce exciting results • do not assume this won’t happen to your paper • besides, referees expect the information • Do not provide wrong information • Sometimes hard to provide all details in available space • may be forced to omit some information • judge what is most essential to the experiments • cite a tech report for more information

34. Discuss related work • Explain how your work relates to state of the art • Discuss relevant past work by other people too • Remember, they may be reviewing your paper. • Avoid: The scheme presented by FOO performs terribly • Prefer: The scheme by FOO does not perform as well in scenario X as it does in scenario Y • Avoid offending people, unless you must

35. Tell them your shortcomings • If your ideas do not work well in some interesting scenarios, tell the reader • People appreciate a balanced presentation

36. How to write weak results • If results are not that great, come up with better ones • Do not hide weak results behind bad writing • Be sure to explain why results are weaker than you expected • If you must publish: write well, but may have to go to second-best conference • Only a few conferences in any area are worth publishing in • Too many papers in poor conferences bad for your reputation • Just because a conference is “IEEE” or “ACM” or “International” does not mean it is any good • If results not good enough for a decent conference, rethink your problem/solution

37. Miscellaneous • Read some well-written papers • award-winning papers from conferences • Avoid long sentences • If you have nothing to say, say nothing • don’t feel obliged to fill up space with useless text • if you must fill all available space, use more line spacing, greater margins, bigger font, bigger figures, anything but drivel

38. How to present a poster • Answer Five Heilmeier Questions • 1. What is the problem you are tackling? • 2. What is the current state-of-the-art? • 3. What is your key make-a-difference concept or technology? • 4. What have you already accomplished? • 5. What is your plan for success? • Do opposite of Bad Poster commandments • Poster tries to catch the eye of person walking by • 9 page poster might look like Problem Statement State-of-the-Art Key Concept Accomplish -ment # 1 Accomplish -ment # 2 Title and Visual logo Accomplish -ment # 3 Summary & Conclusion Plan for Success

39. How to present a paper(at a conference) • Objectives, in decreasing order of importance • Keep people awake and attentive • everything has been tried: play fiddle, cartoons, jokes • in most cases, extreme measures should not be needed • humor can help • Get the problem definition across • people in audience may not be working on your problem • Explain your general approach • most productive use of your time • Dirty details • most people in the audience probably do not care • a typical conference includes 30+ paper presentations, yours could be the N-th

40. How many slides? • Depends on personal style • Rules of thumb • 1 slides for 1-2 minutes • Know your pace • I tend to make more slides than I might need, and skip the not-so-important ones dynamically • Anticipate technical questions, and prepare explanatory slides

41. How to present a paper • Practice makes perfect (or tolerable) • May need several trials to fit your talk to available time • particularly if you are not an experienced speaker • English issue • Accent may not be easy to understand • Talk slowly • Easier said than done • I have a tough time slowing down myself

42. The rest of the notes Overview/Review: • Internet protocol stack • IP protocol • TCP protocol If you forget these materials, go back and review what you learned in CS118 ASAP

43. Packet Switched Networks • Hosts send data in packets • network supports all data communication services by delivering packets • Web, email, multimedia Host Host video Application Host Web Host Host email

44. One network application example Jim@lcs.mit.edu Dave@cs.ucla.edu msg

45. email Dave@cs.ucla.edu Jim@lcs.mit.edu msg Transport protocol Transport protocol Network protocol Network protocol Network protocol Network protocol physical net Physical net Physical net What is happening inside ?

46. A C B physical connectivity Protocol layers Layered Network Architecture • network consists of geographically distributed hosts and switches (nodes) • Nodes communicate with each other by standard protocols host switch A B C D network topology

47. a picture of protocol layers A Application (data) header data Transport segment header DATA network packet tail DATA header Ethernet frame B physical connectivity What’s in the header: info needed for the protocol’s function

48. TCP/IP Protocol Suite • IP Protocol: Inter-networking protocol • RFC791 • TCP Protocol: reliable transport protocol • RFC793

49. Why IP • a number of different network technologies developed in early 70’s: ARPAnet, Ethernet, Satnet, PRnet • different trans. media: copper, radio, satellite • different protocol designs, e.g. • ARPAnet: reliable message delivery • Ethernet: unreliable packet delivery • under different administrative control

50. Fundamental Goal of IP • developing an effective technique for multiplexed utilization of all existing networks • no centralized control • no changes to individual subnets To read next time “The Design Philosophy of Internet Protocols” by Dave Clark, SIGCOMM'88