1. CS211: Protocol and Systems Design for Wireless and Mobile Networks
Instructor: Songwu Lu
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
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
Wireless Cell
Mobile Host

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

7. Protocol Stack Application Layer Middleware and OS Transport Layer
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 reading assignment:
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
to 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:

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 Theme of the solution
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 s, 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. Do unto others as you would have them do unto you
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.

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 Avoid long sentences
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
Title and
Visual logo
Accomplish
-ment # 2
Accomplish
-ment # 3
Plan for Success
Summary &
Conclusion

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. Accent may not be easy to understand Talk slowly Easier said than done
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, , multimedia
Host
Host
video
Application
Host
Web
Host
Host

44. One network application example
msg

45. What is happening inside ?
msg
Transport
protocol
Network
protocol
Physical net
physical net

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

47. a picture of protocol layers
Application (data)
header
data
Transport segment
header
DATA
network packet
header
DATA
tail
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

51. The picture of the world according to IP
application protocols
TCP UDP
transport
(end-to-end)
transport layer protocols
universal datagram delivery IP
inter-network layer
subnets
hardware-specific
network technologies
ethernet token-ring FDDI dialup ATM

52. IP Packet Header Format
vers IHL Type-of-Service total length
identifier
fragment offset
time-to-live
protocol
checksum
source address
destination address
options (variable length)
padding
data DF MF

53. IP: two basic functions
a globally unique address for each reachable interface
datagram delivery from any host to any other host(s)
two supporting protocols
ICMP (Internet Control Message Protocol)
ARP (Address Resolution Protocol)

54. Fundamental challenge: How to scale better
Original design: two levels of hierarchy, network, host
Observed problems:
class-based address assignment infeasible
too many networks visible at the top level
two approaches: subnetting & (CIDR) supernetting

55. Longer-Term Scaling issues
We've run out of all IPv4 unicast space
far before theoretical limit of 4 billion hosts, due to inevitable inefficiency of address block allocation
Short term patch: NAT boxes
One long term solution: IP version 6
expanded addressing capability: 16 bytes
cleanup of IPv4 design after 15 years of running experience
improved support for options/extensions

56. The IPv6 Header Version Priority Flow Label Payload Length Next Header
Hop Limit
Source Address
Destination Address
 32 bits 

57. The IPv4 Header shaded fields are absent from IPv6 header Version
Hdr Len
Prec
TOS
Total Length
Identification
Flags
Fragment Offset
Time to Live
Protocol
Header Checksum
Source Address
Destination Address
Options
Padding
 32 bits 
shaded fields are absent from IPv6 header

58. TCP: Transmission Control Protocol
a transport protocol
IP delivers packets “from door to door”
TCP provides full-duplex, reliable byte-stream delivery between two application processes
Application process
Application process
More terminology:
TCP segment
Max. segment
size (MSS) W
rite
Read
bytes
bytes
TCP
TCP
Send buffer
Receive buffer
segment
segment

59. TCP: major functionalities
Header format
Connection Management
Open, close
State management
Reliability management
Flow and Congestion control
Flow control: Do not flood the receiver’s buffer
Congestion control: Do not stress the network by sending too much too fast

60. TCP header format IP header data source port destination port16 31
IP header
source port
destination port
Data sequence number
acknowledgment number
u a p r s f
r c s s y i
g k h t n n
Hlen unused
window size
checksum
urgent pointer
Options (viable length)
data

61. opening a connection: three-way hand-shake
client
open request(x)
server
Passive open
ack(x+1) + request(y)
ack(y+1)
(now in estab. state)
enter estab. state

62. Closing a TCP Connection
I-finished(M)
ACK (M+1)
I-finished(N)
ack(N+1)
wait for 2MSL
before deleting
the conn state
Done, delete conn. state

63. Mechanisms for Reliability Management
Sequence number
Acknowledgment number
Error detection at the receiver side
Retransmission timeout

64. TCP Flow and Congestion Control
Window-based protocol
Flow control is easy: set the sender’s window no larger than the advertised window by the receiver
4 algorithms in TCP congestion control
Control congestion window variable: cwnd
slow start, congestion avoidance, fast retransmit and fast recovery, retransmission upon timeout
Sender_window=min(adv_win, cwnd)

65. Slow Start & Congestion Avoidance
start conservatively: cwnd <= min(2*SMSS bytes, 2 segments)
when cwnd <ssthresh, use slow start:
increase cwnd exponentially to quickly fill up the pipe: upon receiving each ACK, cwnd+=SMSS;
when cwnd > ssthresh, use congestion avoidance
cwnd += SMSS*SMSS/cwnd;
continue until loss is detected

66. Fast Retransmit
When the 3rd DUP_ACK is received, ssthresh=max(FlightSize/2, 2*SMSS)
ReXmit the lost segment, set cwnd=ssthresh+3*SMSS
Design questions:
why FlightSize, not cwnd ?
FlightSize: data sent but not yet acked
Why add 3 SMSS to cwnd ?

67. Fast Recovery For each additional DUP_ACK: When a NEW ACK arrives,
cwnd+=SMSS; (why ?)
transmit a new segment if min(cwnd, rwnd) permits
When a NEW ACK arrives,
cwnd=ssthresh; (why ?)

68. Retransmission Timeout
Initial design:
RTT=*old_RTT+ (1-)*New_RTT_sample
RTO= *RTT;  = 2 for original spec
variation in RTT: ~1/(1-L); factor 4, for L=50%; factor 10, for L=80%; load <= 30% for =2.
RTO improvement
in addition to mean, also estimate the deviation of RTT
Diff=New_RTT_sample - old-RTT;
Smoothed_RTT=old_RTT+1/8*Diff
Dev=old_RTT+1/4*(|Diff|-Old_Dev)
RTO = Smoothed_RTT+4*Dev

69. Karn’s Algorithm how to measure RTT in retransmission cases?
take the delay between the first (last) transmission and final ack?
do not update SRTT in case of retransmission?
Karn’s algorithm:
do not take RTT samples in case of retransmission
double the retransmission timer for next packet, till one can get a RTT sample without retransmission

70. Putting all together: RFC2581
how TCP congestion control works
Start with slow start for bootstrapping phase: quickly open up the window
At ssthresh, switch to congestion avoidance
When 3rd duplicate ACK is received (indicating a packet loss), use fast retransmit; if more than 3 duplicate ACKs, use fast recovery
Upon retransmission timeout (indicating a packet loss too): cwnd=1, binary exponential backoff