Module F

Transport Layer over Wireless Networks + Voice over IP (VoIP)

JP Hubaux

With help from P. Papadimitratos and M. Poturalski

Mobile Networks

http://mobnet.epfl.ch

Some slides addapted from Jochen H. Schiller, Nitin Vaidya, and James Kurose & Keith Ross

Outline

g TCP in Mobile Networks

g Real-time traffic in Mobile Networks

2

Reminder: Transmission Control Protocol (TCP)

g Reliable, in-order data delivery

g Flow control

g Congestion avoidance and control

g End-to-end semantics

Host A Host B

SYN, Seq_no = x

SYN, Seq_no = y, ACK, Ack_no = x+1

Seq_no = x+1, ACK, Ack_no = y+1

3

TCP basic operation

Send buffer

Segments

Receive buffer

Application writes bytes in send buffer

ACKsSender Receiver

Application reads bytes from receive buffer

Application layer

Transport layer

Write 45 bytesWrite 15 bytesWrite 20 bytes

Read 40 bytesRead 40 bytes

InternetInternet4

TCP flow control

g Flow control is a speed-matching servicei Sender adjusts the transmission rate to the receiver

g Receiver advertises the remaining buffer space (rwnd)to the sender

g The sender keeps unacknowledged data below rwndLastByteSent – LastByteAcked ≤ rwnd

5

Congestion

Light traffic i Arrival Rate << Ri Low delayi Can accommodate more

Congestion onseti Arrival rate approaches R i Delay increases rapidlyi Throughput begins to saturate

Saturationi Arrival rate > Ri Large delays, packet lossi Useful application throughput

drops

Th

rou

ghp

ut (

bp

s)D

ela

y (s

ec)

R

R

Arrival Rate

Arrival Rate

6

TCP congestion control

g Keeps TCP off the congestion collapse cliff

g Congestion window mechanismLastByteSent – LastByteAcked ≤ min{cwnd, rwnd}

g Slow Start phasei Increase congestion window size (cwnd) by one segment for each

received ACKi Congestion window increases exponentially

ACK

Segment

Time (expressed in RTTs)

cwnd

7

TCP congestion control

g Congestion Avoidance phasei Congestion threshold ssthresh

i When cwnd > ssthresh, increase cwnd slowly

i cwnd++ per round-trip-time (RTT)

• Each time an ACK arrives, cwnd is increased by 1/cwnd

• In one RTT, cwnd segments are sent, so total increase in cwnd is cwnd x 1/cwnd = 1

•cwnd grows linearly

cwnd

ssthresh

8

Time (expressed in RTTs)

TCP congestion control

g Congestion detection: i Timeout or

i Receipt of duplicate ACKs(Fast Retransmit)

g Assumption: current cwnd corresponds to available bandwidth

g TCP Tahoei ssthresh = ½ cwnd

i cwnd = 1

i Go back to Slow Start g Over several cycles expect to

converge to ssthresh equal to about ½ the available bandwidth

Co

ng

esti

on

win

do

w

0

SlowStart

CongestionAvoidance

Time-out

ssthresh

9Time (expressed in RTTs)

TCP congestion control

g Fast Retransmit mechanismi If a segment is dropped,

subsequent segments trigger duplicate ACKs

i Sender retransmits segment instantly (without waiting for a timeout) when duplicate ACKs are received (typically 3)

g Improves performancei Faster reaction to packet loss

g Implemented in TCP-Reno (more recent than TCP-Tahoe)

SEQ=1ACK=1

ACK=1ACK=1ACK=1

SEQ=2SEQ=3SEQ=4SEQ=5

10

Wireless and Mobile Networks

Mobile Host (1)Access Point

InternetInternet

Base Station

Mobile Host (2)

Wireline Communication

Wireless Communication

11

Wireless and Mobile Networks

Mobile Host (1)Access Point

InternetInternet

g Wireless transmission errors

i High Bit Error Rates

i Packet (frame) loss 12

Wireless and Mobile Networks

InternetInternet

Base Station(A) Mobile Host (2)

Base Station(B) Mobile Host (2)

g Mobility

i Disconnection

i Hand-offs

i Delays 13

Challenge

g TCPi Assumptions for the Wire-line Internet

• Packet loss only due to congestion

• Packet loss is rare

g Wireless and mobile networksi TCP assumptions are not valid

g Problem: TCP under-performs i TCP cannot distinguish between packet losses due to

congestion and transmission or disconnection errors

i Reducing the congestion window when an error or a disconnection occurs is not necessary

i Throughput suffers14

Questions

g What can we do about…i transmission errors?

i errors due to mobility?

g Which part of the system functionality should we modify…i The sender?

i The receiver?

i An intermediate node?

i Some or all of the above?

15

Directions

g Transmissions errorsi Hide error losses from the sender

• If the sender is unaware of the packet losses due to errors, it does not reduce the congestion window

i Inform sender of packet loss cause

• If the loss is due to an error, the congestion window is not reduced

g Errors due to mobilityi Hide mobility from the TCP sender

i Make TCP adaptive to mobility

16

Solution classification

g Split-connection approachesi Split a TCP connection into two: the wire-line part and wire-

less part at a Base Station or Access Point (Foreign Agent)

g Link layer approachesi Improve link layer reliability

g End-to-end approachesi Modify TCP congestion control mechanism

g Hybrid approaches

17

Split-connection approaches

18

Indirect TCP (I-TCP)

g Split the TCP connection at the AP into two partsi AP buffers and retransmits received segments

i AP sends ACKs for the received segmentsg Standard TCP on the wire-line linkg On the wireless link:

i TCP optimized for wireless

i Even standard TCP benefits from shorter RTT

• Shorter timeout

• Faster retransmissions

Mobile HostAccess Point (AP)Internet

“Wireless” TCPStandard TCP

19

I-TCP example

Mobile HostCorrespondent Host Access Point

ack 1

segment 2

ack 2

segment 3

ack 3

segment 1

segment 1

ack 1

segment 2

segment 3

segment 2

segment 2timeout

(short timeout thanks to short RTT)

ack 2

ack 3

20

I-TCP and mobility

g Moving to a new access point requires transfer of socket statei Including segments buffered at the FA

Mobile Host Access point (1)

Internet

Access Point (2)

Socket migrationand state transfer

21

I-TCP summary

g I-TCP Advantagesi No changes in the fixed network or hosts (TCP protocol), all current

TCP optimizations still work

• Potentially no changes in mobile hosts

i Wireless transmission errors do not “propagate” to the wire-line network

g I-TCP Disadvantagesi Loss of end-to-end semantics

• An ACK does not imply that the receiver got the segment

• For mobility support, all FAs need to be I-TCP compatible, and the state needs to be transferred to maintain end-to-end semantics

i Higher end-to-end delays due to buffering and forwarding to a new agent

i Problem with security mechanisms, e.g. IPsec

• FA needs to spoof ACKs

22

Mobile TCP (M-TCP)

g Handling of long and frequent disconnectionsg Splits connection at FA as I-TCP doesg Foreign agent

i No caching, no retransmission

i Monitors all packets

i If it detects a disconnection (no ACKs from MN for a while)

• Reports rwnd = 0 to sender

• Sender automatically goes into “persist” mode: Does not timeout or in any other way change the congestion window

Mobile HostAccess Point (Foreign Agent)Internet

“Wireless” TCPStandard TCP

23

M-TCP summary

g M-TCP advantagesi End-to-end semantics preserved

i Moving to another FA does not require forwarding buffered packets to new FA (since FA does no buffering)

g M-TCP disadvantagesi Wireless link loss propagates to the wire-line network

i Packets lost due to link errors need to be retransmitted by the sender

i Problems with security mechanisms (just like I-TCP)

g M-TCP handles mobility errors, not transmission errors24

Snooping TCP

g “TCP-Aware Link Layer”g Splits connection like I-TCP and M-TCP

i FA buffers and retransmits segments (if necessary)

i FA does not ACK buffered packets as I-TCP does (preserves end-to-end semantics)

Internet

Buffering of data

End-to-end TCP connection

Local Retransmission CorrespondentHostForeign

Agent

MobileHost

Snooping of ACKs

25

Snooping TCP: data transfer

g Data transfer to the Mobile Hosti FA buffers a segment until it receives an ACK from the MHi FA detects segment loss via duplicate ACKs or a timeout

• FA timeout is shorter than the round-trip timeout (RTO) at the sender

i FA locally retransmits lost segmentsi FA drops duplicated ACKs from MH

• Prevents unnecessary retransmissions and congestion window reductions at the sender

• Does not violate end-to-end semantics:Even if the FA crashes before MH receives the segment, the sender will eventually detect the loss via a timeout and retransmit

26

Snooping TCP: data transfer

g Data transfer from the Mobile Hosti FA detects segment loss on the

wireless link via missing sequence numbers

i FA triggers retransmission of lost segment at MH

• E.g., with a NACK mechanismi MH retransmits data with a much

shorter delay

Mobile HostForeign Agent

SEQ=1000

SEQ=1100

SEQ=1200

NACK=1100

SEQ=1100

27

Snooping TCP and mobility

g When the MH moves to a new FA, should the buffered segments be transferred from the old FA?

i Not necessary

• Even if some of the buffered segments are lost in the transition, the sender will eventually timeout and retransmit them

• This preserves end-to-end semantics

i Yet, this buffer transfer would improve performance because the timeout puts the sender into slow start phase

28

Snooping TCP summary

g Snooping TCP advantagesi End-to-end semantics preserved

i Transfer of buffered segments not necessary during handoff

• MH can move to FA without Snoop TCP support

g Snooping TCP disadvantagesi Does not isolate wireless link failures as well as I-TCP does

• If FA takes too long to retransmit a segment, CH will timeout

i Requires modifications at Mobile Host

• NACK or similar mechanism to force retransmission

i Snooping cannot be done if TCP headers are encrypted (like in IPsec EPS; application layer security, e.g. TLS, is compatible)

i Dropping duplicate ACKs can break integrity

29

Performance enhancing proxies (PEP)

g Transport layer proxiesi Local retransmissions and acknowledgementsi Any of the approaches reviewed above qualifies

g Application layer proxiesi HTTP, FTP, …i Content caching, filtering, compression, picture downscaling

g Big problem: breaks security end-to-end semanticsi Disables use of IP securityi Choose between PEP and security!

Mobile Host PEP Corr. Host

wireless

Internet

Link layer approaches

31

Forward Error Correction (FEC)

g FEC: Introduce redundancy in the packet, allowing a receiver to correct a limited number of errors

g Increasingly popular in wireless standardsi Repetition and Hamming codes in Bluetooth

i Convolutional codes in IEEE 802.11a

i Reed-Solomon + convolutional codes in WiMax

i Turbo codes in HSDPA

i LDPC in IEEE 802.11n and 802.11ac

g Helps to avoid retransmissionsi Shorter and less variable transmission time

g Increases computational and bandwidth overheadi Less of a concern nowadays thanks to Moore’s law

32

Efficient link layer handoff: IEEE 802.11r

g Handoff without IEEE 802.11r1. MH discovers new AP

2. MH authenticates with new AP

3. MH (re)associates with new AP

4. MH and new AP generate and confirm shared temporal keys (based on PSK or IEEE 802.1X)

5. MH requests QoS resources

6. Data communication with new AP can start

communication with old AP still possible

communication with old AP no longer possible

g IEEE 802.11r allows key generation and QoS resource allocation (steps 4 and 5) to take place prior or during (re)association (step 3)

33

End-to-end approaches

34

Fast Retransmit and Fast Recovery

g Assumptionsi Congestion causes many segments to

be droppedi If a single segment is dropped, but the

triggered duplicate ACKs are delivered, the network is probably not congested

g Hencei No need for drastic reduction of

congestion window (as in TCP Tahoe)i Fast Recovery phase

SEQ=1ACK=1

ACK=1ACK=1ACK=1

SEQ=2SEQ=3SEQ=4SEQ=5

35

TCP Tahoe vs TCP Reno

g 3 duplicate ACKs arrivei Fast Retransmit: instantly

retransmit 1st lost segmenti ssthresh = ½ cwnd i cwnd = 1i Enter Slow Start

g 3 duplicate ACKs arrivei Fast Retransmit: instantly

retransmit 1st lost segmenti ssthresh = ½ cwnd i cwnd = ssthresh + 3i Enter Fast Recovery

g Fast Recoveryi Increase cwnd by 1 segment

for every duplicate ACK received

i When new ACK received•cwnd = ssthresh• Enter Congestion Avoidance

i If a timeout occurs• Reset cwnd to 1

• Enter Slow Start

36

Every duplicate ACK received indicates a delivered segment A new segment can be transmitted

TCP Reno vs TCP new-Reno

g Fast Recoveryi Increase cwnd by 1

segment for every duplicate ACK received

i When new ACK received•cwnd = ssthresh• Enter Congestion

Avoidancei If a timeout occurs

• Reset cwnd to 1

• Enter Slow Start

g Fast Recovery (FR)i Note last segment transmitted

before entering FR as ni Increase cwnd by 1 segment

for every duplicate ACK received

i When new partial ACK received (for k < n)• Retransmit 1st unacked

segment

• Remain in Fast Recoveryi When ACK for n received

•cwnd = ssthresh• Enter Congestion Avoidance

i If a timeout occurs• Reset cwnd to 1

• Enter Slow Start

37

Performance comparison of TCP variants

g With single packet lost in congestion window, TCP Reno and TCP new-Reno avoid Slow Start, and outperform TCP Tahoei cwnd oscillates around the optimal

g With multiple packet lost per congestion window (not shown in the figure), TCP Reno underperforms severely; new-Reno introduced to resolve thisi Bursty packet loss common in mobile networks

cwnd

10

5

15

20

0

Slowstart

Congestionavoidance

Time-out

Triple duplicate ACK

38

Behavior of Reno and new-Reno

Time (expressed in RTTs)

Selective acknowledgment (SACK)

g TCP acknowledgements are cumulativei ACK n acknowledges correct and in-sequence receipt of

packets up to ni The sender only learns about the first lost segment

• What if more segments are lost?g Selective retransmission as one solution

i RFC2018 allows for acknowledgments of single packets, not only acknowledgments of in-sequence packet streams without gaps

i Sender can retransmit missing packets more efficientlyg Advantage

i Higher efficiencyg Disadvantage

i More complex software in the receiver, more buffer needed at the receiver (CPU-, memory- and power-constraint MH)

39

Long disconnections

g TCP doubles RTO (Retransmit Time Out) each time a timeout occursi Can cause unnecessary idle time after longer disconnection

Mobile Host

Correspondent Host

MH disconnected

timeout

MH connected

connection idle

segment n+

1

segment n+

1

segment n+

1

segment n+

1

segment n+

1

40

Long disconnections

g TCP doubles RTO each time a timeout occursi Can cause unnecessary idle time after longer disconnection

g A Mobile Host aware of connection state can “wake up” the CHi Trigger fast retransmit with duplicate ACKs

g Simple solutioni No changes at CH necessary

i But TCP at MH needs to be aware of connectivity

Mobile Host

Correspondent Host

MH disconnected

timeout

MH connected

segment n+

1

segment n+

1

segment n+

1

segment n+

1

ack

n

segment n+

1

Fast Retransmission triggered

41

Explicit notification approaches

g Explicit congestion notification i Instead of TCP indirectly inferring congestion, let routers

and/or other hosts inform the sender/receiver directly

i Requires changes to TCP and the routing infrastructure

g Explicit bad state notificationi Base Station/Access Point (FA) keeps track of wireless link

conditions

i Bad link conditions are signal to the Correspondent Host

i Correspondent Host reacts accordingly

• Reduces/freezes transmission rate

• Resumes transmission at previous rate when good state notification arrives

i Requires using a FA and making changes to TCP at all hosts

42

Conclusions

g Many proposed techniquesg Different characteristics and requirements

g TCP used in more heterogeneous networks nowadaysi Mobile networks

i Over satellite linksg Can a single TCP protocol perform in these settings?g Or should we develop specialized TCP versions (and split TCP

connections when possible)?

43

Referencesg H. Elaarg, Improving TCP Performance over Mobile Networks, ACM Computing

Surveys, Vol. 34, No. 3, September 2002g Y. Tian, K. Xu, and N. Ansari. TCP in Wireless Environments: Problems and Solutions.

IEEE Radio Communications, March 2005g J. Huang et al. Anatomizing Application Performance Differences on Smartphones.

ACM MobiSys 2010g A. Bakre, B.R. Badrinath. I-TCP: Indirect TCP for Mobile Hosts. ICDCS 1995g K. Fall, S. Floyd. Simulation-based comparisons of Tahoe, Reno and SACK TCP. ACM

Sigcomm 1996g K. Brown, S. Singh. M-TCP: TCP for mobile cellular networks. ACM Sigcomm 1997g H. Balakrishnan, S. Seshan , R. H. Katz. Improving reliable transport and handoff

performance in cellular wireless networks. Wireless Networks. Volume 1, Issue 4, 1995 (this is the reference addressing Snooping TCP)

g J. Border , M. Kojo , J. Griner , G. Montenegro , Z. Shelby. Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. RFC 3135, June 2001

g W. Wei, C. Zhang, H. Zang, J. Kurose, and D. Towsley. Inference and Evaluation of Split-Connection Approaches in Cellular Data Networks. PAM 2006

g M. Mathis, J. Mahdavi, S. Floyd, A. Romanov. TCP selective acknowledgment options. RFC 2018, October 1996

g K. Ramakrishnan, S. Floyd, D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, September 2001

g B.S. Bakshi, P. Krishna, N.H. Vaidya, D.K. Pradhan. Improving Performance of TCP over Wireless Networks. ICDCS 1997

44

Real-Time Traffic in Wireless Networks

g TCPi Reliable in-order delivery (no loss)

i Delay-tolerant

i Throughput optimization

g Real-time traffici Delay-sensitive

i Loss-tolerant

i Constant throughput requirements

g We focus on VoIP i Represents the most demanding interactive real-time traffic

45

VoIP

g Call establishment protocolsi SIP, H.323, …

g Transport protocolsi RTP, RTCP, …

g Audio (voice) codecsi ITU G.711, ITU G.722, ITU G.729, GSM, …

46

SIP: Session Initiation Protocol

g SIP long-term vision:i All telephone calls, video conference calls take place over

Internet

i People are identified by names or e-mail addresses, rather than by phone numbers

i You can reach callee, no matter where callee roams, no matter what IP device callee is currently using

g Note: technically SIP is an application layer protocoli However, provided functionality not too different from Mobile

IP or HIP

47

SIP Services

g Setting up a calli Establishing a connection between caller and callee

i Negotiation of media type, encoding

i Call termination

g Callee localizationi Map mnemonic identifier to current IP address

g Call managementi Add new media streams during call

i Change encoding during call

i Invite others

i Transfer, hold calls

48

Setting up a call to known IP address

g Alice’s SIP invite message indicates heri Port number

i IP address

i Preferred encoding to receive (PCM μLaw)

g Bob’s 200 OK message indicates hisi Port number

i IP address

i Preferred encoding (GSM)

g SIP messages can be sent over TCP or UDPi Here sent over

RTP/UDP

49time time

Bob'stermina l rings

A lice

167.180.112.24

Bob

193.64.210.89

port 38060

Law audio

G SMport 48753

Setting up a call (more)

g Codec negotiationi Bob can reject proposed codec with 606 Not Acceptable Replyand include a list of supported codecs

i Alice can then send new INVITE message, advertising different encoder

g Rejecting a calli Bob can reject with replies “busy,” “gone,” “payment

required,” “forbidden”

g Media can be sent over RTP or some other protocol

50

Name translation and user location

g Caller knows only callee’s name or e-mail addressg Need to get IP address of callee’s current host

i User moves around, changing IP address

i User has different IP devices (PC, PDA, car device)

g Result can be based oni Time of day (work, home)

i Caller (don’t want boss to call you at home)

i Status of callee (calls sent to voicemail when callee is already talking to someone)

g Service provided by SIP serversi SIP registrar server

i SIP proxy server51

SIP Registrar

52

g When Bob starts SIP client, client sends SIP REGISTER message to Bob’s registrar server

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89

From: sip:bob@domain.com

To: sip:bob@domain.com

Expires: 3600

Register Message:

SIP Proxy

g Alice sends invite message to her proxy serveri Contains address sip:bob@domain.com

g Proxy responsible for routing SIP messages to calleei Possibly through multiple proxies

g Callee sends response back through the same set of proxies.

g Proxy returns SIP response message to Alice i Contains Bob’s IP address

g Proxy analogous to local DNS server

53

ExampleCaller jim@umass.edu places a call tokeith@upenn.edu

(1) Jim sends INVITEmessage to umass SIPproxy(2) Proxy forwardsrequest to upenn registrar server (3) upenn server returnsredirect response,indicating that it should try keith@epfl.ch(4) umass proxy sends INVITE to epfl registrar(5) Epfl registrar forwards INVITE to 197.87.54.21 (keith’s SIP client)(6-8) SIP response sent back(9) media sent directly between clients. Note: there is also a SIP ack message, which is not shown

SIP client217.123.56.89

SIP client197.87.54.21

SIP proxyum ass.edu

SIP registrarupenn.edu

SIPregistrareurecom .fr

1

2

34

5

6

7

8

9

54

epfl.ch

Comparison with H.323

g H.323 is a signaling protocol for real-time interactive traffici Alternative to SIP

g H.323 is a complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport, codecs

g SIP is a single component. Works with RTP, but does not mandate it. Can be combined with other protocols, services

g H.323 comes from the ITU (telephony).g SIP comes from IETF: Borrows much of its concepts from HTTP

i SIP has Web flavor, whereas H.323 has telephony flavor. g SIP uses the KISS principle: Keep it simple and stupid !

55

Real-Time Protocol (RTP)

g RTP specifies packet structure for packets carrying audio, video data

g RTP runs in end hostsg RTP packets encapsulated in UDP

segmentsi RTP encapsulation is only seen at end

systems (not by intermediate routers) g RTP does not provide any mechanism to

ensure timely data delivery or other QoS guaranteesi Routers provide best-effort service,

making no special effort to ensure that RTP packets arrive at destination in timely matter

56

RTP Example

g Consider sending 64 kbps PCM-encoded voice over RTPg Application collects encoded data in chunks, e.g., every 20

msec = 160 bytes in a chunk. g Audio chunk + RTP header form RTP packet, which is

encapsulated in UDP segment g RTP header indicates type of audio encoding in each packet

i Sender can change encoding during conference g RTP header also contains sequence numbers, timestamps

57

Real-Time Control Protocol (RTCP)

g Works in conjunction with RTPg Each participant in RTP session periodically transmits

RTCP control packets to all other participants g Each RTCP packet contains sender and/or receiver

reports about useful statisticsi # packets sent

i # packets lost

i Inter-arrival jitter

i …

g Feedback can be used to control performancei Sender may modify its transmissions based on feedback

58

VoIP and the link layer

g Micro-mobility support for VoIPi Efficient layer 2 handover (already covered)

g Real-time traffic over the link layeri Cellular networks link layer designed with real-time traffic in

mind

i We focus on real-time traffic over IEEE 802.11

59

VoIP over IEEE 802.11 DCF

g DCF (Distributed Coordination Function) is a best-effort servicei No QoS guarantees on channel access delay

i Contention for the channel

i Unlucky node can experience significant delays

60

t

medium busy SIFS

PIFS

DIFSDIFS

next framecontention

direct access if medium is free DIFS time slot

IEEE 802.11 DFC: VoIP onlyg Many experimental and analytical evaluations

i 5 to tens of connections can be supported (depending on codec and voice chunk duration)

g Example (AP handles VoIP connection only):

G.729: audio data compression algorithm

g Rapid performance collapse with too many voice connections

61

Rat

io o

f pac

kets

dela

yed

>15

0ms

Number of voice connections

Taken from [Cai06]Downlink traffic,IEEE 802.11b,rate 11Mbps,ns2 simulations

IEEE 802.11e

g IEEE 802.11e defines Quality-of-Service (QoS) extensions to IEEE 802.11

g Two new channel access methods:i Enhanced Distributed Channel Access (EDCA)

• Extension of DCF

• 4 traffic classes with different priorities

i (Hybrid Coordination Function)-Controlled Channel Access (HCCA)

• Similar to PCF

62

EDCA

g EDCA: Enhanced Distributed Channel Accessg EDCA defines 4 traffic classes with different priorities (listed

from highest to lowest priority)i Voice, Video, Best-effort, Background

g Channel access method as in DCFg Each class uses different values of parameters

i Arbitration Interframe Space (AIFS)

i Backoff (BO) contention window size range (CWmin, CWmax)

63

t

medium busy SIFS

PIFS

AIFS[0]

next framecontention

AIFS[1]

AIFS[2]AIFS[3]

CW

EDCA

g To prioritize traffic internally EDCA makes use ofi Separate queue for

each class

i A virtual collision handler

64

Priority-based distribution

queue 3

BackoffAIFS[3]BO[3]

queue 1

BackoffAIFS[1]BO[1]

queue 2

BackoffAIFS[2]BO[2]

queue 0

BackoffAIFS[0]BO[0]

Virtual collision handler

Frame to transmit

Transmission attempt

IEEE 802.11e summary

g Best-effort prioritizing of trafficg Connections in the same class contend as with DCF

i Adding a few too many voice connections degrades the performance significantly for all nodes

g Hence need for admission controli Prevents oversubscribing to a channel

i Provides some control over latency

i Challenge: overlapping BSSs

g Security concernsi Misbehaving stations could attempt to assign highest priority

to their traffic

65

References

g L.Cai, Y. Xiao, X.S. Shen, J.W. Mark. VoIP over WLAN: voice capacity, admission control, QoS, and MAC: Research Articles. International Journal of Communication Systems, Volume 19, Issue 4, May 2006

g L.X. Cai, X. Shen, J.W. Mark, L. Cai, Y. Xiao. Voice capacity analysis of WLAN with unbalanced traffic. IEEE Transactions on Vehicular Technology vol. 55, no. 3, May 2006

g J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. SIP: Session Initiation Protocol. RFC 3261, June 2002

g H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A Transport Protocol for Real-Time Applications. RFC 3550, July 2003

66

My Research Focus:Privacy Protection

67

g Trends

i More technology: more computing power, more bandwidth, more collection of personal data

i More wearable devices (including more lifestyle trackers) better feedback loop

Data mining, machine learning

Data mining, machine learning

Cookies, browser fingerprints, clicks,content of emails, data from OSN,…Heart rate, gaze, sounds, sweat,…

Optimized stimuli (ads) to maximize likelihood of purchase decision

A Few Ongoing Research Projectsin my Group (LCA1)

g Genome privacyg Smart permission management in Androidg Location-based activity summary

68

69

Why Protect Genomic Data?

g Genome carries information about a person’s genetic condition and predispositions to specific diseasesi Leakage of such information could cause

genetic discrimination

i Denial of access to health insurance, mortgage, education, and employment

70

Things are Moving

g CS giants start proposing genome-related services

o Google Genomics (API to store, process, explore, and share DNA data)o IBM Research (computational genomics)o Microsoft Research (genomic research in collaboration with Sanger

Center)o Amazon

g Global Alliance for Genomics & Health

o Definition of a common framework for effective, responsible and secure sharing of genomic and clinical data

o Security Working Group: security infrastructure policy and technologyhttp://genomicsandhealth.org/our-work/working-groups/security-working-group/work-products

71

Ongoing Collaborations• Swiss HIV Cohort Study http://www.shcs.ch/

i Infrastructure supporting multi-center (7 hospitals) research project dealing with HIV infected adults

i Our contribution: deployment (next month) of our data protection software on their system

• Lausanne University Hospital (CHUV) – Biobankhttp://www.chuv.ch/biobanque/bil_home/bil-recherche.htm

i Clinical and environmental datai Genomic data:

• 2.5M SNPs / patient• 20’000 patients

i Our contribution: protection of the biobank as of 2016 g Sophia Genetics

i http://www.sophiagenetics.comi Start-up company, on campus; visualization of genomic datai Successfully closed 2nd round of funding (11MCHFrs): Endeavour Vision, Invoke,…i Our contribution: protection of raw genomic data

g Other partners: EPFL School of Life Science, Cornell Tech, Craig Venter Institute, Vanderbilt Univ.,…

72

Smart Permissions (SmarPer)

g Smartphones manage an increasing amount of private information

g Android, the dominant mobile OS, relies on permissions to protect this sensitive information

g Problem: permission model has several limitationsi “All-or-nothing”

i Coarse-grained

i Context-oblivious

i Difficult to understand

i Abused by apps

1/3 apps request excessive permissions

app request

<f1, f2,..,fn>feature vector

SmarPer Overview

10

timelocationphone statusnearby devsconn type

decision & confidenceProcessi

ng

response

yes

no

1 2

3

4

5 6

9

13

14

12

user feedback

8

categorystatusdownloadsreviewsdeveloper

7

app namereq typeparams

11

Interception

Obfuscation

Context

App Info

Audit

ML ModelUpdate

DB

ML Model

c>t

ML Machine Learning

c confidence

t threshold

optional step

Automatic permission decisions using machine learning• Reduce user-burden (e.g., number of manual decisions)

Dynamic permission decisions based on context• E.g., share location at a restaurant but not at the hospital

Better privacy vs. utility trade-offs• Multi-level data obfuscation (e.g., approximate location, filtered contact info)

g Activity-tracking applications are increasingly used

75

• Current solution

Privacy: The online service can track the users’ locations

Security: users can cheat on their performance

We propose SecureRun

Privacy: The online service cannot track the users’ locations

Security: users cannot cheat on their performance

Location-based activity summaries

g SecureRun guarantees location privacy and cheat-resiliencei By providing lower bounds of activity summaries

i Based on networks of access points

76

Location-based activity summaries

Users’ concern levels regarding security (left)

and privacy (right) issues in activity-tracking apps

Users’ satisfaction for various performance levels of SecureRun if the

actual distance is 10 miles

Distribution of FON access points (left) and Garmin activities (right) in Paris

Overall performance of SecureRun

SecureRun’s accuracy level

For Next Semester

g Master’s Research Associate; if you are interested and you qualify, please email me:i Letter of motivation

i CV

i 2 or 3 references

g Projectsi Our project descriptions are online: semester projects,

optional projects, Master theses

77

New Course: CS-622 Privacy Protection

g Doctoral course (6 ECTS credits), first instance in the fall 2014g Bridge between our research and our teaching activitiesg Next instance: September – December 2015g Can be taken by Master’s students (half were Master’s students last year)g Oral exam + mini-project (leading possibly to a publication; can be combined with

semester project / optional project)g Content of the course

i Part 1 - Preliminaries

• 1.1 Introduction

• 1.2 Economics and Incentives

• 1.3 Crypto-Based Solutionsi Part 2 - Data Privacy

• 2.1 Hiding Data from the Database User

• 2.2 – Hiding Access Patterns from the Database Owneri Part 3 - Privacy in Networks

• 3.1 Privacy in the Internet

• 3.2 Privacy in Mobile Networksg Lecturer: JP Hubaux, helped by post-docs and PhD students for the mini-projectsg Access to last year’s material:

i http://moodle.epfl.ch/course/view.php?id=14215i Password for guest access from outside of the Intranet: key PriPro14

78

79