Docstoc

Pattern

Document Sample
Pattern Powered By Docstoc
					                                 Mobile Networks


                                     Module F

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


       JP Hubaux, P. Papadimitratos and M. Poturalski



                             http://mobnet.epfl.ch


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




   TCP in Mobile Networks

   Real-time traffic in Mobile Networks




                                           2
    Reminder: Transmission Control Protocol


                              Host A      Host B
   Reliable, in-order data
    delivery

   Flow control

   Congestion avoidance
    and control

   End-to-end semantics



                                              3
                              TCP basic operation



    Application writes                               Application reads bytes
   bytes in send buffer                                from receive buffer


                       Write 45 bytes
                       Write 15 bytes                         Read 40 bytes
Application layer      Write 20 bytes                         Read 40 bytes
Transport layer
                                        Segments


                    Send buffer                     Receive buffer
                     Sender               ACKs        Receiver

                                        Internet
                                                                      4
                     TCP flow control


   Flow control is a speed-matching service
     Sender adjusts the transmission rate to the receiver

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

   The sender keeps unacknowledged data below rwnd
        LastByteSent – LastByteAcked ≤ rwnd




                                                             5
                             Congestion
Throughput (bps)



                   R                 Light traffic
                                           Arrival Rate << R
                                           Low delay
                                           Can accommodate more

                                     Congestion onset
                           Arrival         Arrival rate approaches R
                            Rate           Delay increases rapidly
                                           Throughput begins to saturate
Delay (sec)




                                     Saturation
                                           Arrival rate > R
                                           Large delays, packet loss
                                           Useful application throughput
                                            drops
                           Arrival
                            Rate                                            6
                       R
                  TCP congestion control
     Keeps TCP off the congestion collapse cliff

     Congestion window mechanism
      LastByteSent – LastByteAcked ≤ min{cwnd, rwnd}
     Slow Start phase
       Increase congestion window size (cwnd) by one segment for each
        received ACK
       Congestion window increases exponentially
                                    cwnd

Segment




   ACK
                                            Time (expressed in RTTs)     7
                 TCP congestion control

   Congestion Avoidance phase
     Congestion threshold ssthresh        cwnd
     When cwnd > ssthresh,
     increase cwnd slowly
    cwnd++ per round-trip-time (RTT)                ssthresh
        • 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

                                           Time (expressed in RTTs)

                                                                      8
                                     TCP congestion control

                        Congestion                     Congestion detection:
                                       Time-out
                        Avoidance                        Timeout or
                                                         Receipt of duplicate ACKs
                                                           (Fast Retransmit)
Congestion window




                                                       Assumption: current cwnd
                                                        corresponds to available
                                                        bandwidth
                           ssthresh                    TCP Tahoe
                                                         ssthresh = ½ cwnd
                                                         cwnd = 1
                                                         Go back to Slow Start
                            Slow                       Over several cycles expect to
                            Start                       converge to ssthresh equal
                                                        to about ½ the available
                                                        bandwidth
                    0

                         Time (expressed in RTTs)                                  9
             TCP congestion control


   Fast Retransmit mechanism
     If a segment is dropped,
     subsequent segments trigger
     duplicate ACKs                     SEQ=1
    Sender retransmits segment         SEQ=2   ACK=1
     instantly (without waiting for a   SEQ=3
     timeout) when duplicate ACKs       SEQ=4
     are received (typically 3)                 ACK=1
                                        SEQ=5   ACK=1
                                                ACK=1
   Improves performance
     Faster reaction to packet loss
   Implemented in TCP-Reno
    (more recent than TCP-Tahoe)


                                                10
              Wireless and Mobile Networks

                     Wire-line Communication


                                        Internet


Mobile Host (1)
                       Access Point


                  Wire-less Communication




                                                   Base Station
                      Mobile Host (2)
                                                           11
              Wireless and Mobile Networks



                                       Internet


Mobile Host (1)
                        Access Point




    Wireless transmission errors
     High Bit Error Rates
     Packet (frame) loss
                                                  12
              Wireless and Mobile Networks



                                          Internet




                   Base Station
Mobile Host (2)        (B)



    Mobility                                        Base Station
     Disconnection     Mobile Host (2)                  (A)

     Hand-offs
     Delays                                                13
                          Challenge

   TCP
     Assumptions for the Wire-line Internet
        • Packet loss only due to congestion
        • Packet loss is rare
   Wireless and mobile networks
    TCP assumptions are not valid

   Problem: TCP under-performs
     TCP cannot distinguish between packet losses due to
     congestion and transmission or disconnection errors
    Reducing the congestion window when an error or a
     disconnection occurs is not necessary
    Throughput suffers
                                                            14
                       Questions

   What can we do about…
    transmission errors?
    errors due to mobility?

   Which part of the system functionality should we
    modify…
    The sender?
    The receiver?
    An intermediate node?
    Some or all of the above?




                                                       15
                          Directions


   Transmissions errors
     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
    Inform sender of packet loss cause
        •If the loss is due to an error, the congestion window is
         not reduced


   Errors due to mobility
     Hide mobility from the TCP sender
     Make TCP adaptive to mobility


                                                                    16
                  Solution classification

   Split-connection approaches
     Split a TCP connection into two: the wire-line part and wire-
       less part at a Base Station or Access Point (Foreign Agent)


   Link layer approaches
     Improve link layer reliability

   End-to-end approaches
     Modify TCP congestion control mechanism

   Hybrid approaches


                                                                     17
Split-connection approaches




                              18
                    Indirect TCP (I-TCP)

                                    Access Point
                                    (Foreign Agent)     Mobile Host
                   Internet



             Standard TCP
                                            “Wireless” TCP

   Split the TCP connection at the FA into two parts
     FA buffers and retransmits received segments
     FA sends ACKs for the received segments
   Standard TCP on the wire-line link
   On the wireless link:
     TCP optimized for wireless
     Even standard TCP benefits from shorter RTT
         • Shorter timeout
         • Faster retransmissions
                                                                      19
                        I-TCP example



Correspondent Host                        Foreign Agent   Mobile Host




                                       segment 2
                                        timeout
             (short timeout thanks to short RTT)                    20
                    I-TCP and mobility



                                    Access Point (2)


               Socket migration
               and state transfer                Internet




Mobile Host                   Access point (1)

     Moving to a new foreign agent (FA) requires transfer
      of socket state
       Including segments buffered at the FA
                                                             21
                       I-TCP summary

   I-TCP Advantages
    No changes in the fixed network or hosts (TCP protocol), all current
     TCP optimizations still work
        •Potentially no changes in mobile hosts
    Wireless transmission errors do not “propagate” to the wire-line
     network


   I-TCP Disadvantages
    Loss of end-to-end semantics
        • An ACK does not imply that the receiver got the segment; what if
        the foreign agent crashes?
        •
        For mobility support, all FAs need to be I-TCP compatible, and the
        state needs to be transferred to maintain end-to-end semantics
    Higher end-to-end delays due to buffering and forwarding to a new
     agent
    Problem with security mechanisms, e.g. IPsec
        •
        FA needs to spoof ACKs                                        22
                   Mobile TCP (M-TCP)

                                   Access Point
                                   (Foreign Agent)      Mobile Host
                  Internet



            Standard TCP
                                           “Wireless” TCP

   Handling of long and frequent disconnections
   Splits connection at FA as I-TCP does
   Foreign agent
    No caching, no retransmission
    Monitors all packets
    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


   M-TCP advantages
    End-to-end semantics preserved
    Moving to another FA does not require forwarding buffered
       packets to new FA (since FA does no buffering)


   M-TCP disadvantages
    Wireless link loss propagates to the wire-line network
    Packets lost due to link errors need to be retransmitted by the
     sender
    Problems with security mechanisms (just like I-TCP)

   M-TCP handles mobility errors, not transmission errors
                                                                 24
        Hybrid approach similar to M-TCP


   The link layer is typically in a better position to detect
    mobility than the transport layer
     Link layer is often aware of ongoing handoffs
     In contrast, M-TCP detects disconnections only after a
       connection is closed, based on missing ACKs


   Hence, the link layer can trigger putting the sender
    (and possibly the MH) into “persistent” mode




                                                             25
                          Snooping TCP

         Local Retransmission                             Correspondent
                                Foreign                   Host
                                Agent
                                               Internet

          Snooping of ACKs           Buffering of data
Mobile
Host                 End-to-end TCP connection



     “TCP-Aware Link Layer”
     Splits connection like I-TCP and M-TCP
       FA buffers and retransmits segments (if necessary)
       FA does not ACK buffered packets as I-TCP does
          (preserves end-to-end semantics)

                                                                   26
            Snooping TCP: data transfer


   Data transfer to the Mobile Host
     FA buffers a segment until it receives an ACK from the MH
     FA detects segment loss via duplicate ACKs or a timeout
        • FA timeout is shorter than the round-trip timeout (RTO) at
        the sender
    FA locally retransmits lost segments
    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


                                                                  27
            Snooping TCP: data transfer


   Data transfer from the Mobile
    Host
     FA detects segment loss on the      Foreign Agent   Mobile Host
     wireless link via missing sequence
     numbers
    FA triggers retransmission of lost
     segment at MH
        •E.g., with a NACK mechanism
    MH retransmits data with a much
     shorter delay




                                                               28
               Snooping TCP and mobility


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

    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


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


                                                                  29
                Snooping TCP summary

   Snooping TCP advantages
    End-to-end semantics preserved
    No changes in the Correspondent Host (CH) required
    Transfer of buffered segments not necessary during handoff
        • MH can move to FA without Snoop TCP support
   Snooping TCP disadvantages
    Does not isolate wireless link failures as well as I-TCP does
        • If FA takes too long to retransmit a segment, CH will timeout
    Requires modifications at Mobile Host
        • NACK or similar mechanism to force retransmission
    Snooping cannot be done if TCP headers are encrypted (like in
     IPsec EPS; application layer security, e.g. TLS, is compatible)
    Dropping duplicate ACKs can break integrity

                                                                          30
     Performance enhancing proxies (PEP)
              wireless
Mobile Host              PEP       Internet          Corr. Host




   Transport layer proxies
     Local retransmissions and acknowledgements
     Any of the approaches reviewed above qualifies
   Application layer proxies
     HTTP, FTP, …
     Content cashing, filtering, compression, picture downscaling

   Big problem: breaks security end-to-end semantics
     Disables use of IP security
     Choose between PEP and security!
                 Deployment in practice


   [Wei06] reports that split-connection (similar to I-
    TCP) and application layer proxies are used by US
    cellular operators (GPRS and CDMA2000 networks)

   Deployed mechanism depends on traffic
                   Operator 1   Operator 2     Operator 3
       FTP         Split-TCP    Split-TCP           No
    HTTP data        Both       Split-TCP       Split-TCP
    HTTP image       Proxy        Proxy           Proxy
     plain TCP        No           No        Split-TCP (option)



                                                              32
Link layer approaches




                        33
         Forward Error Correction (FEC)

   FEC: Introduce redundancy in the packet, allowing a
    receiver to correct a limited number of errors
   Increasingly popular in wireless standards
     Repetition and Hamming codes in Bluetooth
     Convolutional codes in IEEE 802.11a
     Reed-Solomon + convolutional codes in WiMax
     Turbo codes in HSDPA
     LDPC in IEEE 802.11n
   Helps to avoid retransmissions
     Shorter and less variable transmission time
   Increases computational and bandwidth overhead
     Less of a concern nowadays thanks to Moore’s law

                                                          34
     Efficient link layer handoff: IEEE 802.11r


    Handoff without IEEE 802.11r
1.   MH discovers new AP                    communication with
2.   MH authenticates with new AP           old AP still possible
3.   MH (re)associates with new AP
4.   MH and new AP generate and confirm
     shared temporal keys (based on PSK     communication with
     or IEEE 802.1X)                        old AP no longer
5.   MH requests QoS resources              possible
6.   Data communication with new AP can
     start
    IEEE 802.11r allows key generation and QoS
     resource allocation (steps 4 and 5) to take place
     prior or during (re)association (step 3)
                                                            37
End-to-end approaches




                        38
            Fast Retransmit and Fast Recovery




   Assumptions
     Congestion causes many segments to       SEQ=1
     be dropped                                        ACK=1
                                               SEQ=2
    If a single segment is dropped, but the   SEQ=3
     triggered duplicate ACKs are delivered,   SEQ=4
     the network is probably not congested             ACK=1
                                               SEQ=5   ACK=1
   Hence                                              ACK=1
     No need for drastic reduction of
     congestion window (as in TCP Tahoe)
    Fast Recovery phase




                                                       39
               TCP Tahoe vs TCP Reno


   3 duplicate ACKs arrive          3 duplicate ACKs arrive
    Fast Retransmit: instantly       Fast Retransmit: instantly
     retransmit 1st
                  lost segment         retransmit 1st lost segment
    ssthresh = ½ cwnd                ssthresh = ½ cwnd
    cwnd = 1                         cwnd = ssthresh + 3
    Enter Slow Start                 Enter Fast Recovery
                                     Fast Recovery
                                      Increase cwnd    by 1 segment
                                       for every duplicate ACK
                                       received
          Every duplicate ACK
                                      When new ACK received
          received indicates a            • cwnd = ssthresh
          delivered segment               • Enter Congestion Avoidance
          A new segment              If a timeout occurs
          can be transmitted              • Reset cwnd to 1
                                          • Enter Slow Start

                                                                     40
             TCP Reno vs TCP new-Reno


                                      Fast Recovery (FR)
                                       Note last segment transmitted
   Fast Recovery                       before entering FR as n
    Increase cwnd  by 1
                                       Increase cwnd by 1 segment
                                        for every duplicate ACK
     segment for every duplicate        received
     ACK received
    When new ACK received             When new partial ACK
                                        received (for k < n)
        • cwnd = ssthresh                  • Retransmit 1 unacked
        • Enter Congestion
                                                         st
                                             segment
          Avoidance
    If a timeout occurs
                                           • Remain in Fast Recovery
                                       When ACK for n received
        • Reset cwnd to 1                  • cwnd = ssthresh
        • Enter Slow Start                 • Enter Congestion Avoidance
                                       If a timeout occurs
                                           • Reset cwnd to 1
                                           • Enter Slow Start

                                                                    41
    Performance comparison of TCP variants

   With single packet lost in congestion window, TCP Reno and
    TCP new-Reno avoid Slow Start, and outperform TCP Tahoe
     cwnd oscillates around the optimal
                Congestion                         Triple duplicate ACK
                avoidance
        20                    Time-out

        15
     cwnd




        10
                    Slow
                    start
            5                            Behavior of Reno and new-Reno
            0
                             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
     Bursty packet loss common in mobile networks
                                                                          42
        Selective acknowledgment (SACK)

   TCP acknowledgements are cumulative
     ACK n acknowledges correct and in-sequence receipt of
     packets up to n
    The sender only learns about the first lost segment
        •
        What if more segments are lost?
   Selective retransmission as one solution
     RFC2018 allows for acknowledgements of single packets,
     not only acknowledgements of in-sequence packet streams
     without gaps
    Sender can retransmit missing packets more efficiently
   Advantage
     Higher efficiency
   Disadvantage
     More complex software in the receiver, more buffer needed
       at the receiver (CPU-, memory- and power-constraint MH)
                                                                 43
                       Long disconnections
Correspondent Host                 timeout




                                                 connection idle


                 MH disconnected              MH connected
  Mobile Host

        TCP doubles RTO each time a timeout occurs
         Can cause unnecessary idle time after longer disconnection




                                                                       44
                       Long disconnections
Correspondent Host                  timeout   Fast Retransmission triggered




                  MH disconnected               MH connected
  Mobile Host

        TCP doubles RTO each time a timeout occurs
         Can cause unnecessary idle time after longer disconnection
        A Mobile Host aware of connection state can “wake up” the CH
         Trigger fast retransmit with duplicate ACKs
        Simple solution
         No changes at CH necessary
         But TCP at MH needs to be aware of connectivity
                                                                              45
         Transaction oriented TCP (T-TCP)

   TCP phases
     Connection setup, data transmission, connection release
     Using 3-way-handshake needs 3 packets for setup and
     release, respectively
    Thus, even short messages need a minimum of 7 packets!
   Transaction oriented TCP
     RFC1644 describes a TCP version to avoid this overhead
     Connection setup, data transfer and connection release can
     be combined
    Thus, only 2 or 3 packets are needed
   Advantage
     Efficiency for single packet transaction
   Disadvantage
     Requires TCP modifications at all hosts

                                                                46
             Explicit notification approaches


   Explicit congestion notification
     Instead of TCP indirectly inferring congestion, let routers
      and/or other hosts inform the sender/receiver directly
     Requires changes to TCP and the routing infrastructure
   Explicit bad state notification
     Base Station/Access Point (FA) keeps track of wireless link
      conditions
     Bad link conditions are signal to the Correspondent Host
     Correspondent Host reacts accordingly
         •
         Reduces/freezes transmission rate
         •
         Resumes transmission at previous rate when good state
         notification arrives
     Requires using a FA and making changes to TCP at all
      hosts
                                                                    47
                         Conclusions


   Many proposed techniques
   Different characteristics and requirements

   TCP used in more heterogeneous networks nowadays
     Mobile networks
     Over satellite links
     Wide-spanning high-bandwidth networks
   Can a single TCP protocol perform in these settings?
   Or should we develop specialized TCP versions (and split TCP
    connections when possible)?




                                                                   48
                                  References

   H. Elaarg, “Improving TCP Performance over Mobile Networks,” ACM Computing Surveys,
    Vol. 34, No. 3, September 2002
   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
   R. Braden. T/TCP -- TCP Extensions for Transactions Functional Specification. RFC
    1644, July 1994
   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

                                                                                          49
      Real-time traffic in Wireless Networks


   TCP
     Reliable in-order delivery (no loss)
     Delay-tolerant
     Throughput optimization

   Real-time traffic
     Delay-sensitive
     Loss-tolerant
     Constant throughput requirements

   We focus on VoIP
    Represents the most demanding interactive real-time traffic
                                                               50
                           VoIP


   Call establishment protocols
     SIP, H.323, …

   Transport protocols
     RTP, RTCP, …

   Audio (voice) codecs
     ITU G.711, ITU G.722, ITU G.729, GSM, …




                                                51
           SIP: Session Initiation Protocol



   SIP long-term vision:
     All telephone calls, video conference calls take place over
      Internet
     People are identified by names or e-mail addresses, rather
      than by phone numbers
     You can reach callee, no matter where callee roams, no
      matter what IP device callee is currently using


   Note: technically SIP is an application layer protocol
     However, provided functionality not too different from Mobile
       IP or HIP


                                                                    52
                        SIP Services


   Setting up a call
     Establishing a connection between caller and callee
     Negotiation of media type, encoding
     Call termination
   Callee localization
     Map mnemonic identifier to current IP address
   Call management
     Add new media streams during call
     Change encoding during call
     Invite others
     Transfer, hold calls


                                                            53
                     Setting up a call to known IP address
                                                                                    Bob
Alice

                                                                                                Alice’s SIP invite
                                                                                                 message indicates her
        167.180.112.24                                              193.64.210.89                    Port number
                     INVITE bob
                                 @193.64.2
                                                                                                     IP address
                     c=IN IP4 16
                     m=audio 38
                                           10.89
                                 7.180.112.2
                                             4
                                                                                                     Preferred encoding to
                                060 RTP/A
                                           VP 0                                                       receive (PCM μLaw)
                                                               port 5060    Bob's
                                                                            terminal rings
                                                                                                Bob’s 200 OK
                                         200 OK
                                                         .210.89                                 message indicates his
                                         c=IN IP4 193.64
                                         m=audio 48 753 RTP/AVP 3
                 port 5060                                                                           Port number
                                                                                                     IP address
                                           ACK
                                                               port 5060
                                                                                                     Preferred encoding
                                                                                                      (GSM)

                                              m Law audio
                port 38060
                                                                                                SIP messages can be
                                                                                                 sent over TCP or UDP
                                                                                                     Here sent over
                                                                                                      RTP/UDP
                                        GSM
                                                             port 48753




              time                                                       time                                                 54
                 Setting up a call (more)


   Codec negotiation
     Bob can reject proposed codec with
       606 Not Acceptable Reply
       and include a list of supported codecs
    Alice can then send new INVITE message, advertising
       different encoder
   Rejecting a call
     Bob can reject with replies “busy,” “gone,” “payment
       required,” “forbidden”
   Media can be sent over RTP or some other protocol



                                                             55
        Name translation and user location

   Caller knows only callee’s name or e-mail address
   Need to get IP address of callee’s current host
     User moves around, changing IP address
     User has different IP devices (PC, PDA, car device)
   Result can be based on
     Time of day (work, home)
     Caller (don’t want boss to call you at home)
     Status of callee (calls sent to voicemail when callee is
       already talking to someone)


   Service provided by SIP servers
     SIP registrar server
     SIP proxy server
                                                                 56
                    SIP Registrar


   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




                                                   57
                       SIP Proxy


   Alice sends invite message to her proxy server
     Contains address sip:bob@domain.com
   Proxy responsible for routing SIP messages to callee
     Possibly through multiple proxies
   Callee sends response back through the same set of
    proxies.
   Proxy returns SIP response message to Alice
     Contains Bob’s IP address
   Proxy analogous to local DNS server



                                                       58
                                Example
Caller jim@umass.edu                                 SIP registrar
                                                     upenn.edu
places a call to
keith@upenn.edu                                                         SIP
                                                 2                      registrar
                                 SIP proxy                              eurecom.fr
(1) Jim sends INVITE              umass.edu       3
                                                        4
message to umass SIP
proxy
                                       1                7                        5
(2) Proxy forwards
                                           8
request to upenn                                                             6

registrar server
(3) upenn server returns                                  9
                                                                             SIP client
redirect response,              SIP client                                   197.87.54.21
indicating that it should       217.123.56.89

try keith@eurecom.fr
(4) umass proxy sends INVITE to eurecom registrar
(5) eurecom 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
                                                                                 59
                 Comparison with H.323


   H.323 is a signaling protocol for real-time interactive traffic
      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
     SIP has Web flavor, whereas H.323 has telephony flavor.
   SIP uses the KISS principle: Keep it simple and stupid !



                                                                   60
                Real-Time Protocol (RTP)


   RTP specifies packet structure for
    packets carrying audio, video data
   RTP runs in end hosts
   RTP packets encapsulated in UDP
    segments
    RTP encapsulation is only seen at end
       systems (not by intermediate routers)
   RTP does not provide any mechanism to
    ensure timely data delivery or other QoS
    guarantees
    Routers provide best-effort service,
       making no special effort to ensure that
       RTP packets arrive at destination in timely
       matter


                                                     61
                        RTP Example


   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
     Sender can change encoding during conference
   RTP header also contains sequence numbers, timestamps




                                                                  62
       Real-Time Control Protocol (RTCP)


   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
     # packets sent
     # packets lost
     Inter-arrival jitter
     …
   Feedback can be used to control performance
     Sender may modify its transmissions based on feedback
                                                              63
                  VoIP and the link layer


   Micro-mobility support for VoIP
    Efficient layer 2 handover (already covered)

   Real-time traffic over the link layer
     Cellular networks link layer designed with real-time traffic in
      mind
     We focus on real-time traffic over IEEE 802.11




                                                                    64
            VoIP over IEEE 802.11 DCF


   DCF (Distributed Coordination Function) is a best-
    effort service
     No QoS guarantees on channel access delay
     Contention for the channel
     Unlucky node can experience significant delays

    DIFS                       DIFS
                              PIFS
                             SIFS
           medium busy                contention     next frame
                                                                   t
           direct access if
           medium is free  DIFS         time slot



                                                                  65
                            IEEE 802.11 DFC: VoIP only
                  Many experimental and analytical evaluations
                   5 to tens of connections can be supported (depending on codec
                      and voice chunk duration)
                  Example (AP handles VoIP connection only):
delayed >150ms
Ratio of packets




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


                                Number of voice connections

     G.729: audio data compression algorithm


                  Rapid performance collapse with too many voice connections
                                                                                    66
                     IEEE 802.11 PCF

   PCF (Point Coordination Function) was designed in
    part to provide QoS guarantees
   Many drawbacks
     Single point of failure: Access Point
     PCF interleaves polling periods with contention periods; the
     latter can cause unpredictable delays
    Unknown transmission time of polled nodes can introduce
     unpredictable delays
    Trade-off between polling scheme complexity and efficiency
    Not clear how overlapping BSSs in PCF mode should
     interact
    Does not define traffic classes
   Not deployed in practice

                                                                 67
                         IEEE 802.11e


   IEEE 802.11e defines Quality-of-Service (QoS)
    extensions to IEEE 802.11
   Two new channel access methods:
     Enhanced Distributed Channel Access (EDCA)
        • Extension of DCF
        • 4 traffic classes with different priorities
    (Hybrid Coordination Function)-Controlled Channel
      Access (HCCA)
        •Similar to PCF




                                                         68
                                  EDCA
   EDCA: Enhanced Distributed Channel Access
   EDCA defines 4 traffic classes with different priorities (listed
    from highest to lowest priority)
     Voice, Video, Best-effort, Background
   Channel access method as in DCF
   Each class uses different values of parameters
      Arbitration Interframe Space (AIFS)
      Backoff (BO) contention window size range (CWmin, CWmax)
                                AIFS[3]
                             AIFS[2]
                            AIFS[1]
                           AIFS[0]
                           PIFS
                          SIFS
        medium busy                   contention   next frame
                                        CW                         t


                                                                       69
                                       EDCA

                            Frame to transmit

          Priority-based distribution

queue 0      queue 1     queue 2        queue 3
                                                     To prioritize traffic
                                                      internally EDCA
                                                      makes use of
                                                       Separate queue for
                                                        each class
Backoff      Backoff      Backoff       Backoff
AIFS[0]      AIFS[1]      AIFS[2]       AIFS[3]        A virtual collision
 BO[0]        BO[1]        BO[2]         BO[3]          handler


           Virtual collision handler

                           Transmission attempt

                                                                              70
                   IEEE 802.11e summary

   Best-effort prioritizing of traffic
   Connections in the same class contend as with DCF
     Adding a few too many voice connections degrades the
       performance significantly for all nodes
   Hence need for admission control
     Prevents oversubscribing to a channel
     Provides some control over latency
     Challenge: overlapping BSSs
   Security concerns
     Misbehaving stations could attempt to assign highest priority
       to their traffic



                                                                 71
                            References


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




                                                                        72

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:2/1/2012
language:
pages:70
jianghongl jianghongl http://
About