CS211: Protocol and Systems Design for Wireless and Mobile Networks

Instructor: Songwu Lu slu@cs.ucla.edu Office: 4531D BH Lectures: 2:00-3:50am M&W office hours: 4:00-5:00pm M&W
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

Topical Studies
-Wireless security -Sensor networks -QoS and Energy-efficient design -Mesh Networks -MIMO Systems

Mobile Computing - middleware, OS, file sys.

- services, applications CS211/Fall 2003

9/29

Emerging Wireless Networks

Internet Backbone Fixed Host

Base Station

Wireless Cell

Mobile Host

CS211/Fall 2003

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 . I ndus. Assn.

Wireless Data Subscriber (in millions)

12 10 8 6 4 2 0 1997 1998 1999 2000 2001 2002 Source: Strategis M arket Res.

CS211/Fall 2003

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 Transport Layer Network Layer Link Layer & Below
CS211/Fall 2003

Wireless Web, Location Services, etc.

Content adaptation, Consistency, File system Wireless TCP Mobility, Routing QoS 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, Vols I, II, III by Doug Comer TCP/IP Illustrated, Vols 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

CS211/Fall 2003

email to slu@cs.ucla.edu with subject cs211: homework #

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/

cs219@cs.ucla.edu

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

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

 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

Selecting a Problem

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 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 CS211/Fall 2003

read entire paper carefully, and several times

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

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

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

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)
9/29

CS211/Fall 2003

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

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

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

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 Key Concept Accomplish -ment # 2 Summary & Conclusion 9/29

Accomplish Title and -ment # 1 Visual logo Accomplish Plan for -ment # 3 Success CS211/Fall 2003

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,
9/29

yours could be the N-th CS211/Fall 2003

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
9/29

CS211/Fall 2003

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
Web, email, multimedia video
Host Host

Host

Application

Web

Host

Host

email
CS211/Fall 2003 9/29

One network application example

Dave@cs.ucla.edu msg Jim@lcs.mit.edu

CS211/Fall 2003

9/29

What is happening inside ?

Dave@cs.ucla.edu msg Transport protocol Network protocol Physical net
CS211/Fall 2003

email

Jim@lcs.mit.edu Transport protocol

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
host switch
A B C
physical connectivity

D
network topology
CS211/Fall 2003

Protocol layers
9/29

a picture of protocol layers

A Application (data) header data Transport segment header DATA network packet DATA header Ethernet frame
physical connectivity

tail

Whats in the header: info needed for the protocols 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 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

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 transport (end-to-end) IP inter-network layer subnets

universal datagram delivery

hardware-specific network technologies ethernet token-ring FDDI dialup ATM

CS211/Fall 2003

9/29

IP Packet Header Format

vers. IHL Type-of-Service MF
DF

total length fragment offset checksum

identifier time-to-live protocol

source address destination address options (variable length) data padding

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 Application process Read bytes TCP Receive buffer

More terminology: TCP segment Max. segment size (MSS)

Write bytes TCP Send buffer

segment CS211/Fall 2003

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 receivers buffer Congestion control: Do not stress the network by sending too much too fast

CS211/Fall 2003

9/29

TCP header format

0 16 31

IP header
source port destination port Data sequence number acknowledgment number Hlen unused
u a p r c s g k h r s f s y i t n n

window size urgent pointer

checksum

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) enter estab. state

CS211/Fall 2003

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 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_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)
CS211/Fall 2003

RTO = Smoothed_RTT+4*Dev
9/29

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