Download September 29, 2003 - UCLA Computer Science

CS211: Protocol and Systems
Design for Wireless and Mobile
Networks
Instructor: Songwu Lu
[email protected]
Office: 4531D BH
Lectures: 2:00-3:50am M&W
office hours: 4:00-5:00pm M&W
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
A picture of the course coverage
Networking fundamentals: Internet
philosophy and principles
Wireless Protocols
-MAC protocol
-802.11 Standard
- Scheduling
- Mobility management, adhoc routing
- wireless TCP
Mobile Computing
- middleware, OS, file sys.
- services, applications
CS211/Fall 2003
Topical Studies
-Wireless security
-Sensor networks
-QoS and Energy-efficient
design
-Mesh Networks
-MIMO Systems
9/29
Emerging Wireless Networks
Internet
Backbone
Base Station
Fixed Host
Wireless Cell
CS211/Fall 2003
Mobile Host
9/29
Growth of Wireless Users
Wireless Phone Subscribers (in millions)
70
60
50
40
30
20
10
0
1991
1993
1995
1997
Source: cellular telecom. Indus. Assn.
Wireless Data Subscriber (in millions)
12
10
8
6
4
2
0
CS211/Fall 2003
1997 1998 1999 2000 2001 2002
Source: Strategis Market Res.
9/29
The Wi-Fi Space
• It is one of the fastest growing industry
sectors
– 100,000 public hotspots by 2005
• Most notebooks will have embedded wifi card
• Go and check the local hotspots online
– www.ezgoal.com/hotspots/
CS211/Fall 2003
9/29
Protocol Stack
Application Layer
Middleware and OS
• Wireless Web, Location
Services, etc.
 Content adaptation,
Consistency, File system
Transport Layer
 Wireless TCP
Network Layer
 Mobility, Routing
 QoS
Link Layer & Below
CS211/Fall 2003
o Scheduling
o MAC
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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 [email protected] with subject “cs211:
homework #”
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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%
CS211/Fall 2003
9/29
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/
[email protected]
CS211/Fall 2003
9/29
Tips on Doing Research in Graduate School
1.
2.
3.
How to do productive research in graduate school
What are the bad practices you should avoid
Your feedback?
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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.
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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…
CS211/Fall 2003
9/29
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?
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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)
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
Tell them your shortcomings
• If your ideas do not work well in some interesting scenarios,
tell the reader
• People appreciate a balanced presentation
CS211/Fall 2003
9/29
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 secondbest 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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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-ofthe-Art
Accomplish Title and
-ment # 1
Visual logo
Accomplish Plan for
-ment # 3
Success
CS211/Fall 2003
Key
Concept
Accomplish
-ment # 2
Summary &
Conclusion
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
Packet Switched Networks
• Hosts send data in packets
• network supports all data communication
services by delivering packets
Host
– Web, email, multimedia video
Host
Application
Host
Web
Host
Host
email
CS211/Fall 2003
9/29
One network application example
[email protected]
[email protected]
msg
CS211/Fall 2003
9/29
What is happening inside ?
[email protected]
msg
email
[email protected]
Transport
protocol
Transport
protocol
Network
protocol
Physical net
CS211/Fall 2003
Network
protocol
Network
protocol
Physical net
Network
protocol
physical net
9/29
Layered Network Architecture
• network consists of geographically
distributed hosts and switches (nodes)
• Nodes communicate with each other by
standard protocols
A
host
A
C
switch
B
C
D
network topology
CS211/Fall 2003
B
physical connectivity
Protocol layers
9/29
a picture of protocol layers
A
Application (data)
header
data
Transport segment
header
DATA
network packet
DATA
header
Ethernet frame
tail
B
physical connectivity
What’s in the header: info needed for the protocol’s function
CS211/Fall 2003
9/29
TCP/IP Protocol Suite
• IP Protocol: Inter-networking protocol
– RFC791
• TCP Protocol: reliable transport protocol
– RFC793
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
The picture of the world
according to IP
application protocols
transport layer protocols
TCP UDP
universal datagram delivery
transport
(end-to-end)
IP
inter-network layer
subnets
hardware-specific
network technologies ethernet token-ring FDDI dialup ATM
CS211/Fall 2003
9/29
IP Packet Header Format
Type-of-Service
identifier
time-to-live
total length
MF
IHL
DF
vers.
protocol
fragment offset
checksum
source address
destination address
options (variable length)
padding
data
CS211/Fall 2003
9/29
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)
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
The IPv6 Header
Version Priority
Payload Length
Flow Label
Next Header
Hop Limit
Source Address
Destination Address
32 bits
CS211/Fall 2003
9/29
The IPv4 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
CS211/Fall 2003
9/29
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
More terminology:
• TCP segment
• Max. segment
size (MSS)
Write
bytes
Read
bytes
TCP
TCP
Send buffer
Receive buffer
segment
CS211/Fall 2003
Application process
segment
9/29
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
CS211/Fall 2003
9/29
TCP header format
0
3
1
1
6
IP header
source port
destination port
Data sequence number
acknowledgment number
Hlen unused
u a p r s f
r c s s y i
g k h t n n
checksum
window size
urgent pointer
Options (viable length)
data
CS211/Fall 2003
9/29
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)
CS211/Fall 2003
enter estab. state
9/29
Closing a TCP Connection
I-finished(M)
ACK (M+1)
I-finished(N)
ack(N+1)
wait for 2MSL
before deleting
the conn state
CS211/Fall 2003
Done, delete conn. state
9/29
Mechanisms for Reliability
Management
•
•
•
•
Sequence number
Acknowledgment number
Error detection at the receiver side
Retransmission timeout
CS211/Fall 2003
9/29
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)
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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 ?
CS211/Fall 2003
9/29
Fast Recovery
• For each additional DUP_ACK:
– cwnd+=SMSS; (why ?)
– transmit a new segment if min(cwnd, rwnd)
permits
• When a NEW ACK arrives,
– cwnd=ssthresh; (why ?)
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29
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
CS211/Fall 2003
9/29