CS211:%20%20Protocol%20and%20Systems%20Design%20for%20Wireless%20and%20Mobile%20Networks

1
CS211 Protocol and Systems Design for Wireless
and Mobile Networks

• Instructor Songwu Lu
• slu_at_cs.ucla.edu
• Office 4531D BH
• Lectures 200-350am MW
• office hours 400-500pm MW

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, Vols I, II, III
  by Doug Comer
• TCP/IP Illustrated, Vols 1 2 by Stevens

10
Course Workload

• One midterm, no final exam
• Midterm November 10th, in class.
• reading assignment
• 12-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 1200pm(noon) before lecture
  on the due date
• email to slu_at_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
• 510 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
  1200pm 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_at_cs.ucla.edu

15
Tips on Doing Research in Graduate School

1. How to do productive research in graduate school
2. What are the bad practices you should avoid
3. 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 (Contd)

• 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 1010 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 retrospectAnyone
  could have thought of that
• Complexity cost is in longer design,
  construction, test, and debug
• Fast changing field delays gt 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 whats 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 cant be proven wrong, then you cant
  prove youre right
• Report in sufficient detail for others to
  reproduce results
• cant convince others if they cant 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 Pattersons experience industry is
  reluctant to embrace change
• Howard Aiken, circa 1950
• The problem in this business isnt 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 doesnt 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
  writers fault
• If I cannot understand the paper, I cannot reject
  it
• Dont 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.htm
  l

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 wont 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
• dont 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
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
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_at_lcs.mit.edu
Dave_at_cs.ucla.edu
msg
45
What is happening inside ?

46
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
Whats in the header info needed for the
protocols 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 70s
• 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
inter-network layer
IP
subnets
hardware-specific network technologies
ethernet token-ring FDDI dialup ATM
52
IP Packet Header Format
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
Flow Label
Version
Priority
Payload Length
Next Header
Hop Limit
Source Address
Destination Address
57
The IPv4 Header
Version
Hdr Len
Total Length
Prec
TOS
Identification
Fragment Offset
Flags
Time to Live
Protocol
Header Checksum
Source Address
Destination Address
Padding
Options
 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 receivers buffer
• Congestion control Do not stress the network by
  sending too much too fast

60
TCP header format
31
0
16
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 connectionthree-way hand-shake
client
open request(x)
server
Passive open ack(x1) request(y)
ack(y1) (now in estab. state)
enter estab. state
62
Closing a TCP Connection

I-finished(M)
ACK (M1)
I-finished(N)
ack(N1) 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 senders 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_windowmin(adv_win, cwnd)

65
Slow Start Congestion Avoidance

• start conservatively cwnd lt min(2SMSS bytes, 2
  segments)
• when cwnd ltssthresh, use slow start
• increase cwnd exponentially to quickly fill up
  the pipe upon receiving each ACK, cwndSMSS
• when cwnd gt ssthresh, use congestion avoidance
• cwnd SMSSSMSS/cwnd
• continue until loss is detected

66
Fast Retransmit

• When the 3rd DUP_ACK is received,
  ssthreshmax(FlightSize/2, 2SMSS)
• ReXmit the lost segment, set cwndssthresh3SMSS
• 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
• cwndSMSS (why ?)
• transmit a new segment if min(cwnd, rwnd) permits
• When a NEW ACK arrives,
• cwndssthresh (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 L50
  factor 10, for L80 load lt 30 for ?2.
• RTO improvement
• in addition to mean, also estimate the deviation
  of RTT
• DiffNew_RTT_sample - old-RTT
• Smoothed_RTTold_RTT1/8Diff
• Devold_RTT1/4(Diff-Old_Dev)
• RTO Smoothed_RTT4Dev

69
Karns 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?
• Karns 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) cwnd1, binary exponential backoff