Mobile Networks Module F Transport Layer over Wireless Networks + Voice over IP (Vo. IP) JP Hubaux With help from P. Papadimitratos and M. Poturalski 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 g Reliable, in-order data delivery Host A Host B SYN, S eq_no = Flow control no = , Seq_ g g Congestion avoidance and control End-to-end semantics x o= Ack_n K, x+1 y, AC SYN Seq_ no = x+ 1, AC K, Ac k_no = y+1 3
TCP basic operation Application writes bytes in send buffer Application layer Application reads bytes from receive buffer Write 45 bytes Write 15 bytes Write 20 bytes Transport layer Read 40 bytes Segments Send buffer Sender Receive buffer ACKs Internet Receiver 4
TCP flow control g Flow control is a speed-matching service g Receiver advertises the remaining buffer space (rwnd)to the sender g The sender keeps unacknowledged data below rwnd i. Sender adjusts the transmission rate to the receiver Last. Byte. Sent – Last. Byte. Acked ≤ rwnd 5
Throughput (bps) Congestion Light traffic R i i i Arrival Rate << R Low delay Can accommodate more Congestion onset Delay (sec) Arrival Rate i i i Arrival rate approaches R Delay increases rapidly Throughput begins to saturate Saturation i i i R Arrival Rate Arrival rate > R Large delays, packet loss Useful application throughput drops 6
TCP congestion control g Keeps TCP off the congestion collapse cliff g Congestion window mechanism g Slow Start phase Last. Byte. Sent – Last. Byte. Acked ≤ min{cwnd, rwnd} i. Increase congestion window size (cwnd) by one segment for each received ACK i. Congestion window increases exponentially cwnd Segment ACK Time (expressed in RTTs) 7
TCP congestion control g Congestion Avoidance phase i. Congestion threshold ssthresh i. When cwnd > ssthresh, increase cwnd slowly icwnd++ per round-trip-time (RTT) • Each time an ACK arrives, cwnd is increased by 1/cwnd • In one RTT, cwnd segments cwnd ssthresh are sent, so total increase in cwnd is cwnd x 1/cwnd = 1 cwnd grows linearly • Time (expressed in RTTs) 8
TCP congestion control Congestion Avoidance Time-out g Congestion detection: i. Timeout or i. Receipt of duplicate ACKs Congestion window (Fast Retransmit) g ssthresh Slow Start 0 Time (expressed in RTTs) g g Assumption: current cwnd corresponds to available bandwidth TCP Tahoe issthresh = ½ cwnd icwnd = 1 i. Go back to Slow Start Over several cycles expect to converge to ssthresh equal to about ½ the available bandwidth 9
TCP congestion control g Fast Retransmit mechanism i. 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 ACK=1 Improves performance g SEQ=1 SEQ=2 SEQ=3 SEQ=4 SEQ=5 Implemented in TCP-Reno (more recent than TCP-Tahoe) i. Faster reaction to packet loss 10
Wireless and Mobile Networks Wireline Communication Internet Mobile Host (1) Access Point Wireless Communication Base Station Mobile Host (2) 11
Wireless and Mobile Networks Internet Mobile Host (1) g Access Point Wireless transmission errors i. High Bit Error Rates i. Packet (frame) loss 12
Wireless and Mobile Networks Internet Mobile Host (2) g Base Station (B) Mobility i. Disconnection i. Hand-offs i. Delays Mobile Host (2) Base Station (A) 13
Challenge g TCP i. Assumptions for the Wire-line Internet • Packet loss only due to congestion • Packet loss is rare g Wireless and mobile networks g Problem: TCP under-performs i. TCP assumptions are not valid 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 suffers 14
Questions g What can we do about… g Which part of the system functionality should we modify… itransmission errors? ierrors due to mobility? i. The sender? i. The receiver? i. An intermediate node? i. Some or all of the above? 15
Directions g Transmissions errors i. 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 mobility i. Hide mobility from the TCP sender i. Make TCP adaptive to mobility 16
Solution classification g Split-connection approaches i. 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 approaches g End-to-end approaches g Hybrid approaches i. Improve link layer reliability i. Modify TCP congestion control mechanism 17
Split-connection approaches 18
Indirect TCP (I-TCP) Internet Access Point (AP) Standard TCP Mobile Host “Wireless” TCP g Split the TCP connection at the AP into two parts g Standard TCP on the wire-line link On the wireless link: g i. AP buffers and retransmits received segments i. AP sends ACKs for the received segments i. TCP optimized for wireless i. Even standard TCP benefits from shorter RTT • Shorter timeout • Faster retransmissions 19
I-TCP example Correspondent Host Access Point Mobile Host segm ent 1 segm ent 2 segm ent 3 segment 1 ack 1 segment 2 ack 1 ack 2 segment 3 ack 3 segment 2 timeout (short timeout thanks to short RTT) 20
I-TCP and mobility Access Point (2) Socket migration and state transfer Mobile Host g Internet Access point (1) Moving to a new access point requires transfer of socket state i. Including segments buffered at the FA 21
I-TCP summary g I-TCP Advantages i. 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 Disadvantages i. 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) Internet Standard TCP g g g Access Point (Foreign Agent) Mobile Host “Wireless” TCP Handling of long and frequent disconnections Splits connection at FA as I-TCP does 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 23
M-TCP summary g M-TCP advantages i. 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 disadvantages i. 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 errors 24
Snooping TCP Local Retransmission Correspondent Host Foreign Agent Internet Mobile Host g g Snooping of ACKs Buffering of data End-to-end TCP connection “TCP-Aware Link Layer” 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) 25
Snooping TCP: data transfer g Data transfer to the Mobile Host i. FA buffers a segment until it receives an ACK from the MH i. 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 segments i. 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 Host i. 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 mechanism i. MH retransmits data with a much shorter delay • Foreign Agent Mobile Host 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 advantages i. 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 disadvantages i. 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) wireless Mobile Host PEP Internet Corr. Host g Transport layer proxies g Application layer proxies g Big problem: breaks security end-to-end semantics i. Local retransmissions and acknowledgements i. Any of the approaches reviewed above qualifies i. HTTP, FTP, … i. Content caching, filtering, compression, picture downscaling i. Disables use of IP security i. Choose between PEP and security!
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 Increasingly popular in wireless standards g Helps to avoid retransmissions g Increases computational and bandwidth overhead g i. Repetition and Hamming codes in Bluetooth i. Convolutional codes in IEEE 802. 11 a i. Reed-Solomon + convolutional codes in Wi. Max i. Turbo codes in HSDPA i. LDPC in IEEE 802. 11 n and 802. 11 ac i. Shorter and less variable transmission time i. Less of a concern nowadays thanks to Moore’s law 32
Efficient link layer handoff: IEEE 802. 11 r g 1. 2. 3. 4. 5. 6. g Handoff without IEEE 802. 11 r MH discovers new AP MH authenticates with new AP MH (re)associates with new AP MH and new AP generate and confirm shared temporal keys (based on PSK or IEEE 802. 1 X) MH requests Qo. S resources Data communication with new AP can start communication with old AP still possible communication with old AP no longer possible IEEE 802. 11 r allows key generation and Qo. S 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 Assumptions i. Congestion causes many segments to be dropped i. If a single segment is dropped, but the triggered duplicate ACKs are delivered, the network is probably not congested g Hence i. No need for drastic reduction of SEQ=1 SEQ=2 SEQ=3 SEQ=4 SEQ=5 ACK=1 congestion window (as in TCP Tahoe) i. Fast Recovery phase 35
TCP Tahoe vs TCP Reno g 3 duplicate ACKs arrive i. Fast Retransmit: instantly g 1 st retransmit lost segment issthresh = ½ cwnd icwnd = 1 i. Enter Slow Start i. Fast Retransmit: instantly retransmit 1 st lost segment issthresh = ½ cwnd icwnd = ssthresh + 3 i. Enter Fast Recovery g Every duplicate ACK received indicates a delivered segment A new segment can be transmitted 3 duplicate ACKs arrive Fast Recovery i. 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
TCP Reno vs TCP new-Reno g g Fast Recovery i. 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 Fast Recovery (FR) i. Note last segment transmitted before entering FR as n i. Increase cwnd by 1 segment for every duplicate ACK received i. When new partial ACK received (for k < n) • Retransmit 1 unacked segment • Remain in Fast Recovery i. When ACK for n received • cwnd = ssthresh • Enter Congestion Avoidance i. If a timeout occurs • Reset cwnd to 1 • Enter Slow Start st 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 Tahoe icwnd oscillates around the optimal 20 Congestion avoidance Triple duplicate ACK Time-out cwnd 15 10 5 0 g Slow start Behavior of Reno and new-Reno Time (expressed in RTTs) With multiple packet lost per congestion window (not shown in the figure), TCP Reno underperforms severely; new-Reno introduced to resolve this i. Bursty packet loss common in mobile networks 38
Selective acknowledgment (SACK) g TCP acknowledgements are cumulative i. ACK n acknowledges correct and in-sequence receipt of packets up to n i. The sender only learns about the first lost segment What if more segments are lost? • g Selective retransmission as one solution i. RFC 2018 allows for acknowledgments of single packets, not only acknowledgments of in-sequence packet streams without gaps i. Sender can retransmit missing packets more efficiently g Advantage g Disadvantage i. Higher efficiency i. More complex software in the receiver, more buffer needed at the receiver (CPU-, memory- and power-constraint MH) 39
Long disconnections timeout Correspondent Host +1 n segment +1 g n segment +1 n segment Mobile Host MH disconnected connection idle MH connected TCP doubles RTO (Retransmit Time Out) each time a timeout occurs i. Can cause unnecessary idle time after longer disconnection 40
Long disconnections +1 n segment +1 n segment Mobile Host MH disconnected Fast Retransmission triggered ack n timeout Correspondent Host MH connected g TCP doubles RTO each time a timeout occurs g A Mobile Host aware of connection state can “wake up” the CH g Simple solution i. Can cause unnecessary idle time after longer disconnection i. Trigger fast retransmit with duplicate ACKs i. No changes at CH necessary i. But TCP at MH needs to be aware of connectivity 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 notification i. 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 techniques Different characteristics and requirements g TCP used in more heterogeneous networks nowadays g Can a single TCP protocol perform in these settings? Or should we develop specialized TCP versions (and split TCP connections when possible)? g g i. Mobile networks i. Over satellite links 43
References g g g H. Elaarg, Improving TCP Performance over Mobile Networks, ACM Computing Surveys, Vol. 34, No. 3, September 2002 Y. Tian, K. Xu, and N. Ansari. TCP in Wireless Environments: Problems and Solutions. IEEE Radio Communications, March 2005 J. Huang et al. Anatomizing Application Performance Differences on Smartphones. ACM Mobi. Sys 2010 A. Bakre, B. R. Badrinath. I-TCP: Indirect TCP for Mobile Hosts. ICDCS 1995 K. Fall, S. Floyd. Simulation-based comparisons of Tahoe, Reno and SACK TCP. ACM Sigcomm 1996 K. Brown, S. Singh. M-TCP: TCP for mobile cellular networks. ACM Sigcomm 1997 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) J. Border , M. Kojo , J. Griner , G. Montenegro , Z. Shelby. Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. RFC 3135, June 2001 W. Wei, C. Zhang, H. Zang, J. Kurose, and D. Towsley. Inference and Evaluation of Split. Connection Approaches in Cellular Data Networks. PAM 2006 M. Mathis, J. Mahdavi, S. Floyd, A. Romanov. TCP selective acknowledgment options. RFC 2018, October 1996 K. Ramakrishnan, S. Floyd, D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC 3168, September 2001 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 TCP g Real-time traffic g We focus on Vo. IP i. Reliable in-order delivery (no loss) i. Delay-tolerant i. Throughput optimization i. Delay-sensitive i. Loss-tolerant i. Constant throughput requirements i. Represents the most demanding interactive real-time traffic 45
Vo. IP g Call establishment protocols g Transport protocols g Audio (voice) codecs i. SIP, H. 323, … i. RTP, RTCP, … i. 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 protocol i. However, provided functionality not too different from Mobile IP or HIP 47
SIP Services g Setting up a call g Callee localization g Call management i. Establishing a connection between caller and callee i. Negotiation of media type, encoding i. Call termination i. Map mnemonic identifier to current IP address i. 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 her i Port number i IP address i Preferred encoding to receive (PCM μLaw) g Bob’s 200 OK message indicates his i Port number i IP address i Preferred encoding (GSM) g SIP messages can be sent over TCP or UDP i Here sent over RTP/UDP 49
Setting up a call (more) g Codec negotiation i. Bob can reject proposed codec with 606 Not Acceptable Reply and include a list of supported codecs i. Alice can then send new INVITE message, advertising different encoder g Rejecting a call i. 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 address Need to get IP address of callee’s current host g Result can be based on g i. User moves around, changing IP address i. User has different IP devices (PC, PDA, car device) i. 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 servers i. SIP registrar server i. SIP proxy server 51
SIP Registrar g When Bob starts SIP client, client sends SIP REGISTER message to Bob’s registrar server Register Message: 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 52
SIP Proxy g Alice sends invite message to her proxy server g Proxy responsible for routing SIP messages to callee g g Callee sends response back through the same set of proxies. Proxy returns SIP response message to Alice g Proxy analogous to local DNS server i. Contains address sip: bob@domain. com i. Possibly through multiple proxies i. Contains Bob’s IP address 53
Example Caller jim@umass. edu places a call to keith@upenn. edu (1) Jim sends INVITE message to umass SIP proxy (2) Proxy forwards request to upenn registrar server (3) upenn server returns redirect 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 epfl. ch 54
Comparison with H. 323 g g g H. 323 is a signaling protocol for real-time interactive traffic i Alternative to SIP H. 323 is a complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport, codecs SIP is a single component. Works with RTP, but does not mandate it. Can be combined with other protocols, services H. 323 comes from the ITU (telephony). SIP comes from IETF: Borrows much of its concepts from HTTP i. SIP has Web flavor, whereas H. 323 has telephony flavor. SIP uses the KISS principle: Keep it simple and stupid ! 55
Real-Time Protocol (RTP) g g g RTP specifies packet structure for packets carrying audio, video data RTP runs in end hosts RTP packets encapsulated in UDP segments i. 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 Qo. S guarantees i. 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 RTP Application collects encoded data in chunks, e. g. , every 20 msec = 160 bytes in a chunk. Audio chunk + RTP header form RTP packet, which is encapsulated in UDP segment RTP header indicates type of audio encoding in each packet g RTP header also contains sequence numbers, timestamps g g g i Sender can change encoding during conference 57
Real-Time Control Protocol (RTCP) g g g Works in conjunction with RTP Each participant in RTP session periodically transmits RTCP control packets to all other participants Each RTCP packet contains sender and/or receiver reports about useful statistics i# packets sent i# packets lost i. Inter-arrival jitter i… g Feedback can be used to control performance i. Sender may modify its transmissions based on feedback 58
Vo. IP and the link layer g Micro-mobility support for Vo. IP g Real-time traffic over the link layer i. Efficient layer 2 handover (already covered) i. Cellular networks link layer designed with real-time traffic in mind i. We focus on real-time traffic over IEEE 802. 11 59
Vo. IP over IEEE 802. 11 DCF g DCF (Distributed Coordination Function) is a besteffort service i. No Qo. S guarantees on channel access delay i. Contention for the channel i. Unlucky node can experience significant delays DIFS medium busy DIFS PIFS SIFS direct access if medium is free DIFS contention next frame t time slot 60
IEEE 802. 11 DFC: Vo. IP only g Many experimental and analytical evaluations i 5 to tens of connections can be supported (depending on codec and voice chunk duration) Example (AP handles Vo. IP connection only): Ratio of packets delayed >150 ms g Taken from [Cai 06] Downlink traffic, IEEE 802. 11 b, rate 11 Mbps, ns 2 simulations Number of voice connections G. 729: audio data compression algorithm g Rapid performance collapse with too many voice connections 61
IEEE 802. 11 e g g IEEE 802. 11 e defines Quality-of-Service (Qo. S) extensions to IEEE 802. 11 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 g EDCA: Enhanced Distributed Channel Access EDCA defines 4 traffic classes with different priorities (listed from highest to lowest priority) i. Voice, Video, Best-effort, Background g g Channel access method as in DCF Each class uses different values of parameters i Arbitration Interframe Space (AIFS) i Backoff (BO) contention window size range (CWmin, CWmax) AIFS[3] AIFS[2] AIFS[1] medium busy AIFS[0] PIFS SIFS contention CW next frame t 63
EDCA Frame to transmit Priority-based distribution queue 0 queue 1 queue 2 queue 3 g To prioritize traffic internally EDCA makes use of i. Separate queue for Backoff AIFS[0] BO[0] Backoff AIFS[1] BO[1] Backoff AIFS[2] BO[2] Backoff AIFS[3] BO[3] each class i. A virtual collision handler Virtual collision handler Transmission attempt 64
IEEE 802. 11 e summary g g Best-effort prioritizing of traffic 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 control g Security concerns i. Prevents oversubscribing to a channel i. Provides some control over latency i. Challenge: overlapping BSSs i. Misbehaving stations could attempt to assign highest priority to their traffic 65
References g g L. Cai, Y. Xiao, X. S. Shen, J. W. Mark. Vo. IP over WLAN: voice capacity, admission control, Qo. S, and MAC: Research Articles. International Journal of Communication Systems, Volume 19, Issue 4, May 2006 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 J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. SIP: Session Initiation Protocol. RFC 3261, June 2002 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 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 Cookies, browser fingerprints, clicks, content of emails, data from OSN, … Heart rate, gaze, sounds, sweat, … Optimized stimuli (ads) to maximize likelihood of purchase decision 67
A Few Ongoing Research Projects in my Group (LCA 1) g g g Genome privacy Smart permission management in Android Location-based activity summary 68
69
Why Protect Genomic Data? g Genome carries information about a person’s genetic condition and predispositions to specific diseases i 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 o g Google Genomics (API to store, process, explore, and share DNA data) IBM Research (computational genomics) Microsoft Research (genomic research in collaboration with Sanger Center) Amazon Global Alliance for Genomics & Health o o Definition of a common framework for effective, responsible and secure sharing of genomic and clinical data Security Working Group: security infrastructure policy and technology http: //genomicsandhealth. org/our-work/working-groups/securityworking-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) – Biobank http: //www. chuv. ch/biobanque/bil_home/bil-recherche. htm i Clinical and environmental data i Genomic data: • 2. 5 M SNPs / patient • 20’ 000 patients i. Our contribution: protection of the biobank as of 2016 g g Sophia Genetics i http: //www. sophiagenetics. com i Start-up company, on campus; visualization of genomic data i Successfully closed 2 nd round of funding (11 MCHFrs): Endeavour Vision, Invoke, … i Our contribution: protection of raw genomic data Other partners: EPFL School of Life Science, Cornell Tech, Craig Venter Institute, Vanderbilt Univ. , … 72
Smart Permissions (Smar. Per) g g g Smartphones manage an increasing amount of private information Android, the dominant mobile OS, relies on permissions to protect this sensitive information Problem: permission model has several limitations i“All-or-nothing” i. Coarse-grained i. Context-oblivious i. Difficult to understand i. Abused by apps Ø 1/3 apps request excessive permissions
Smar. Per Overview § 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) Audit response user feedback 12 9 app request 7 Interception 1 10 2 app name req type params 8 11 DB 13 Obfuscation time location phone status nearby devs conn type Context ML Model Update yes 14 3 Processi ng <f 1, f 2, . . , fn> feature vector 5 ML Model decision & confidence c>t 6 no category status downloads reviews developer App Info 4 ML Machine Learning c confidence t threshold optional step
Location-based activity summaries • Current solution g Activity-tracking applications are increasingly used We propose Secure. Run Privacy: The online service can track the users’ locations Security: users can cheat on their performance Privacy: The online service cannot track the users’ locations Security: users cannot cheat on their performance 75
Location-based activity summaries g Secure. Run guarantees location privacy and cheatresilience i. By providing lower bounds of activity summaries i. Based on networks of access points Distribution of FON access points (left) and Garmin activities (right) in Paris Users’ concern levels regarding security (left) and privacy (right) issues in activitytracking apps Overall performance of Secure. Run’s accuracy level Users’ satisfaction for various performance levels of Secure. Run if the actual distance is 10 miles 76
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 Projects i. Our project descriptions are online: semester projects, optional projects, Master theses 77
New Course: CS-622 Privacy Protection g g g Doctoral course (6 ECTS credits), first instance in the fall 2014 Bridge between our research and our teaching activities Next instance: September – December 2015 Can be taken by Master’s students (half were Master’s students last year) Oral exam + mini-project (leading possibly to a publication; can be combined with semester project / optional project) Content of the course i i i g g Part 1 - Preliminaries 1. 1 Introduction 1. 2 Economics and Incentives 1. 3 Crypto-Based Solutions Part 2 - Data Privacy 2. 1 Hiding Data from the Database User 2. 2 – Hiding Access Patterns from the Database Owner Part 3 - Privacy in Networks 3. 1 Privacy in the Internet 3. 2 Privacy in Mobile Networks • • Lecturer: JP Hubaux, helped by post-docs and Ph. D students for the mini-projects Access to last year’s material: i i http: //moodle. epfl. ch/course/view. php? id=14215 Password for guest access from outside of the Intranet: key Pri. Pro 14 78
79
Скачать презентацию Mobile Networks Module F Transport Layer over Wireless
517e80b702cf6588cd6427eaae609352.ppt