Your SlideShare is downloading. ×
0
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

E Multipoll Fec Persistence Portals

230

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
230
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Multipoll, FEC, Persistence, Portals Greg Chesson, greg@atheros.com Aman Singla, aman@atheros.com
  • 2. Multipoll poll description
    • CF-Poll
      • Both downlink and uplink data movement are provided
      • Consider only uplink because Multipoll does not provide downlink
      • Uplink sequences:
          • Pn denotes the nth poll
          • Ui denotes the ith uplink frame
            • P1 <SIFS> U1 <SIFS> P2 <SIFS> U2 <SIFS> CF-End
            • P1 <SIFS> U1 <SIFS> P2 <no response> <PIFS> P3 <SIFS> U3 <SIFS> CF-End
            • Pi contains ACK for Ui-1
      • Airtime for N polls and uplink frames
        • N * (frame header + SIFS) + N*(uplink frames + SIFS) + CF-End
        • Assume headers are sent at low PHY rate
        • Assume uplink frames at higher PHY rate if possible
  • 3. Multipoll multipoll description
    • CF-Multipoll
      • Uplink or sidelink only: assigns N fixed-duration TxOPs to stations
        • Each station transmits after the previous station’s TxOPLimit (+SIFS)
        • Entire TxOPLimit period is always used (even on short uplink frames)
            • Use all the time all the time
        • Non-response by station consumes the entire TxOPLimit slot
            • Not so for CF-Poll
      • Multipoll sequences
            • MP[1-N] <SIFS> U1 <SIFS> U2 <SIFS> <no response> <SIFS> U4 // U3 damaged
            • MP[1-N] ********************************************* // damaged MP
      • Airtime for N polls
            • MP Header + NStations*4 + N*(TxOPLimit + SIFS)
  • 4. Multipoll Timing at 6 Mb/s seconds Number of polled stations Poll Multipoll Large frames (2K) Small frames (100B)
  • 5. Multipoll Timing at 36 Mb/s Large frames (2K) Small frames (100B) CF-Poll Multipoll seconds Number of Polled Stations
  • 6. Multipoll comparison
    • Airtime improvement (reduction) using multipoll instead of polls
      • assumes no errors and no wasted airtime
      • Improvement is real, but small
    • Penalties for using multipoll
      • Entire allocated timeslot wasted on non-responding stations
        • Expect this to happen on channel errors where MP is not received by all
        • Not a problem with poll: coordinator recovers after PIFS if no response
      • TxOplimit allocation must be set and processed for each timeslot
        • Ongoing complexity for HC and stations (ESTA must parse entire MP frame)
        • No variable timing or state needed with poll (one poll rather than variable N)
      • Unused portion of timeslot is dead airtime (not reclaimed)
        • Creates vulnerability from OBSS, DCF, and ad hoc stations
        • Can become less efficient than per-station polling (no similar dead time)
        • Not a problem with poll: uplink uses airtime only as needed
      • ACK policy
        • Not part of multipoll protocol, must become part of uplink handshake or come from a different ACK mechanism, introducing inefficiency and delay either way
        • Not a problem with poll: ACKs are built-into the sequence of poll messages
  • 7. Multipoll Resolution
    • Multipoll as proposed does not provide broad efficiency improvements
    • Multipoll as proposed has numerous penalities
    • Multipoll, even without channel errors, can be less efficient than poll
    • Proposal:
      • Delete Multipoll and all references
      • Use CF-Poll instead of Multipoll
      • Allow CF-Poll syntax for use by HC at any time
        • Subject to channel access rules for HC (when they are finalized)
  • 8. FEC observations
    • Raw channel data:
      • packet error rate (PER) as function of (range, PHY rate, frame size).
      • Single transmitter, no interference, packet losses caused by channel
    • PER increases with higher PHY rates, distance, larger frames.
    • 11a and 11b systems show similar behavior
      • Knee of PER curve at approx 10% PER, except for lowest PHY rate
    Distance PER 10% 90%
  • 9. FEC successful application
    • FEC in satellite/broadcast downlinks
      • PER of 10^-6 needed for high-quality mpeg-2 video
      • Retransmission not possible
        • it’s a broadcast-only downlink
        • FEC must succeed (reduce PER to 10^-5 or better)
      • per-frame FEC reduces PER by approx 10^-2 (only)
      • Therefore, conservative (slow) PHY rates must be chosen
        • Raw downlink PHY must have approx 1% PER (before FEC)
        • FEC then reduces packet loss rate to 10^-4 or 10^-5
    • Note: high-quality video
      • 8 Mbit/s base rate
      • May burst to 12 Mbit/s or so
      • Needs 500 frames/sec if 2KByte frames are used
  • 10. FEC TGe draft proposal
    • FEC in 802.11 MAC
      • Expect 10^-1 (10%) or more packet error rates (PER) for 11a, 11b
        • Based on measurement and expected practice (except for lowest PHY rates)
        • Much higher expected PER than in satellite applications
      • Expect 10^-2 to 10^-3 PER after FEC
        • May need 5 retransmissions/sec for an 8 MBit/s video stream (!)
        • Retransmissions will contribute to increased jitter
      • FEC overhead is
        • 10% payload (redundancy bytes added to header and payload)
        • Plus extra TxOP and airtime for Delayed Ack and its Ack
        • Plus the residual retransmissions
          • Unless slow PHY rate (with 1% PER) is selected (unlikely)
        • This is a lot of overhead when compared to retransmission
  • 11. FEC implementation issues
    • Optimistic/pipelined Decode
      • Header can be validated in pipelined fashion
      • The number of error blocks can be determined in near real-time
      • ACK can be generated in SIFS time, knowing that correction will succeed
    • Delayed ACKs
      • When do you know that a Delayed Ack is not forthcoming?
        • I.e. when do we retransmit?
        • Adds even more delay jitter
      • Sending MAC must maintain state for each non-Acked packet
        • How many such packets?
        • For how long?
      • Receiving MAC needs out-of-order assembly buffers
        • Size is related to delay-bandwidth product of Delayed Acks
        • Size is related to number of Delay-Ack streams
      • What is a minimum interoperable implementation?
      • Need TCP-like sophistication to select good parameters
  • 12. FEC compared to retransmission
    • FEC
      • >10% channel overhead for redundant information
      • Will also need retransmission (unless low PHY rate is used)
      • Will need TCP-like out-of-order assembly and controls
      • Does not improve jitter
    • Retransmission
      • Channel overhead is function of PER – not a constant 10%
      • In-order delivery, no complex state
      • has less overhead than FEC for practical PERs
    • Conclusion
      • FEC may not always be the best procedure
      • FEC may be useful at low PHY rates for broadcast/multicast
      • Delayed ACKs have significant unresolved issues
  • 13. FEC resolution
    • Retain FEC
      • Define Capability bit and FEC-encoded bit
    • Remove Delayed Acks
    • Proceed with two motions and editing instructions from document 01/458
  • 14. Persistence Factor simulation models
    • Must include channel error model
      • Channel measurements show that PER will be significant
      • Simulated Latency-jitter-bandwidth numbers meaningless without PER
        • Especially jitter
      • Should incorporate 10% channel error rate for realism
        • Based on 11ab measurements
        • Based on expectations of rate adaptation implementations
    • Demonstration
      • observe media simulations with and without 10% PER
  • 15. Persistence Simulation Scenario: 4 phones, 2 video, 10 background, EDCF @ 36 Mb/s (packet loss only from collisions) phones videos background Remove loads
  • 16. Persistence Same scenario, adding 10% PER Bandwidth glitches Caused by retransmission Backoff delay when Background load Is applied
  • 17. Persistence (showing latency distribution per flow) Phones: mean = 1.5ms, deviation = 5+ms Videos: mean = 15+ms, deviation = 30 ms Not good
  • 18. Persistence Backoff-related Jitter Demonstrated with PER
    • “ Optimistic” (no PER) simulation suggests that life is wonderful.
    • “ Realistic” (PER) simulation shows unacceptable jitter for media streams.
    • Proposed solutions (both in Tge draft proposal)
      • Persistence Factor
        • Defines fractional exponent per TC instead of binary exponential backoff
        • Hi-priority traffic would increase backoff window at slower (fractional) rate
        • Implementation complexity: must compute uniform distributions over non-power-of-two windows (considered costly)
        • Good for stream (slow rate of increasing backoff)
        • Bad for channel (can increase congestion because of slow backoff increases)
      • aCWMax[TC]
        • Already present in MIB
        • Provides upper bound for backoff window based on traffic category
        • Retains simple power-of-two computations and scaling from existing MACs
        • Good for stream (limits backoff window to an upper bound)
        • Good for channel (fast backoff increase)
  • 19. Persistence Same scenario using CWMax[TC] to bound retransmission window for video and voice traffic Bandwidth aberrations removed Lower background Bandwidth peaks
  • 20. Persistence Improved latency and jitter for media flows retransmission jitter becomes negligible Phones before: mean = 1.5ms, deviation = 5+ms after: mean = [.95,1.6], deviation = [.7,1.98] Videos before: mean = 15+ms, deviation = 30 ms after: mean = [1.8,2.3], deviation = [1.7,2.2]
  • 21. Persistence Resolution
    • Both mechanisms are in the draft standard
    • Both mechanisms solve the problem (reduce backoff-related jitter)
    • aCWMax[TC]
      • Is better from a channel perspective (fast backoff to a limit)
      • Is less complex (uses existing CWMin/CWMax and random generator)
    • Persistence Factor
      • Not as good from a channel perspective (can increase contention)
      • Is more complex (adds fractional scaling, requires new random generator)
    • Proposal
      • Remove the redundant mechanism (Persistence)
      • Move aCWMax[TC] from MIB to QoS Parameter Set Element CWMax[TC]
  • 22. Bridge Portals state of the art
    • Useful concept
    • Non-802.11 bridges
      • Define unique protocols for discovery, routing, announcement, etc
      • CableLabs-defined QoS bridges invoke RSVP/SBM
      • IPv6 provides Neighbor Discovery protocol and messages
      • Bluetooth has Service Discovery Protocol
      • Universal Plug and Play (UPNP) is a candidate discovery layer
    • Should 802.11 define Yet Another Protocol (YAP) for Discovery?
      • No compelling reason
      • Unlikely to improve on existing art
      • Very unlikely to replace existing art
    • Should 802.11 be usable with existing protocols?
      • Absolutely
      • Requires both 802.11 DS and non-802.11 DS
  • 23. Bridge Portals simple approach
    • Implement multiple station addresses in MAC
      • “ multi-homing”, but at Layer 2
    • Use one address to associate with BSS
    • Use others to communicate with BPs
    • Use BP-unique protocols to locate and acquire services
      • No need to provide non-802.11 discovery services in 802.11
    • Notes:
      • Technique mentioned by Michael Fischer and others
      • Some implementations may already exist
      • Useful technique for mobility protocols
      • Equivalent to simultaneous membership in both BSS and IBSS
      • Requires no new 802.11 protocol

×