CS211:%20%20Protocol%20and%20Systems%20Design%20for%20Wireless%20and%20Mobile%20Networks - PowerPoint PPT Presentation

About This Presentation



CS211/Fall 2003. 9/29. CS211: Protocol and Systems Design for Wireless and ... line spacing, greater margins, bigger font, bigger figures, anything but drivel ... – PowerPoint PPT presentation

Number of Views:200
Avg rating:3.0/5.0
Slides: 71
Provided by: Lixia8
Learn more at: https://www.cs.ucla.edu


Transcript and Presenter's Notes

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

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

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

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

Emerging Wireless Networks
Internet Backbone
Base Station
Fixed Host
Mobile Host
Wireless Cell
Growth of Wireless Users
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/

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
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

  • 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

Course Workload
  • One midterm, no final exam
  • Midterm November 10th, in class.
  • reading assignment
  • 12-page summary for the assigned reading of each
  • 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

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

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

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
  • term project 40
  • proposal 5, checkpoint 10, final report 15,
    presentation demo 10

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

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?

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

  • 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
  • This presentation may not follow some rules it
    talks about

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

A Few EQ Rules
  • Motivation you are indeed interested in PhD
  • 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
  • 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.

EQ Rules (Contd)
  • Regular life manage your time and life
  • Shift from deadline scheduling to priority
  • 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
  • Keep your most productive time-slot during a day
    to yourself
  • No interruption even by your advisor, full
  • Even when the deadline comes

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
  • 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
  • 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
  • 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

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
  • 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?

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
  • Explore new approaches the alternative/opposite
  • Ask questions based on your intuition
  • Keep things simple unless a very good reason not
  • 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
  • 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

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
  • Papers that are directly relevant to your work
  • read entire paper carefully, and several times

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

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
  • Exchange emails, publish technical reports

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
  • 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
  • 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

  • Publishing papers is not equivalent to marketing
  • Missionary work Sermons first, then they read
  • 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

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

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
  • Dont take chances. Write the paper well.
  • Badly written papers typically do not get read

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)

Writing a draft
  • First read Strunk and White, then follow these
  • 1. 1-page paper outline, with tentative page
  • 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
  • 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

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

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
  • 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

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

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
  • 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

  • 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
  • if you must fill all available space, use more
    line spacing, greater margins, bigger font,
    bigger figures, anything but drivel

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
  • 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
  • 9 page poster might look like

Problem Statement
Key Concept
Accomplish -ment 1
Accomplish -ment 2
Title and Visual logo
Accomplish -ment 3
Plan for Success
Summary Conclusion
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,
  • in most cases, extreme measures should not be
  • humor can help
  • Get the problem definition across
  • people in audience may not be working on your
  • 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

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

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
  • English issue
  • Accent may not be easy to understand
  • Talk slowly
  • Easier said than done
  • I have a tough time slowing down myself

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

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

One network application example
What is happening inside ?

Layered Network Architecture
  • network consists of geographically distributed
    hosts and switches (nodes)
  • Nodes communicate with each other by standard

host switch
network topology
a picture of protocol layers
Application (data)
Transport segment
network packet
Ethernet frame
physical connectivity
Whats in the header info needed for the
protocols function
TCP/IP Protocol Suite
  • IP Protocol Inter-networking protocol
  • RFC791
  • TCP Protocol reliable transport protocol
  • RFC793

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

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

The picture of the world according to IP
application protocols
transport (end-to-end)
transport layer protocols
universal datagram delivery
inter-network layer
hardware-specific network technologies
ethernet token-ring FDDI dialup ATM
IP Packet Header Format
IP two basic functions
  • a globally unique address for each reachable
  • datagram delivery from any host to any other
  • two supporting protocols
  • ICMP (Internet Control Message Protocol)
  • ARP (Address Resolution Protocol)

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

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
  • 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
  • improved support for options/extensions

The IPv6 Header
Flow Label
Payload Length
Next Header
Hop Limit
Source Address
Destination Address
The IPv4 Header
Hdr Len
Total Length
Fragment Offset
Time to Live
Header Checksum
Source Address
Destination Address
 32 bits 
  • shaded fields are absent from IPv6 header

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)

Send buffer
Receive buffer
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

TCP header format
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
urgent pointer
Options (viable length)
opening a connectionthree-way hand-shake
open request(x)
Passive open ack(x1) request(y)
ack(y1) (now in estab. state)
enter estab. state
Closing a TCP Connection

ACK (M1)
ack(N1) wait for 2MSL before deleting the conn
Done, delete conn. state
Mechanisms for Reliability Management
  • Sequence number
  • Acknowledgment number
  • Error detection at the receiver side
  • Retransmission timeout

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)

Slow Start Congestion Avoidance
  • start conservatively cwnd lt min(2SMSS bytes, 2
  • 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

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 ?

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 ?)

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

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

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
Write a Comment
User Comments (0)
About PowerShow.com