Harmonizing Multicast/Broadcast Proposals

1. Harmonizing Multicast/Broadcast Proposals • Authors: • Date: 2008-09-02 Hart et al (Cisco Systems et al)

2. Requirements for Multicast Video Requirements • Very low PLR • Low delay and delay jitter • Multiple transmissions per beacon period • Compatible with legacy STAs • Duplicate detection Objectives • Efficiency (since video throughput can be high) • Feedback for rate adaptation • Compatible with power save • Flexibility (high reliability and efficiency vs high scalability - 100s in MC group) • In harmony with FBMS • SW upgrade for 11n implementations Hart et al (Cisco Systems et al)

3. Options for Sub-Features A2C = AP to client C2A = Client to AP Hart et al (Cisco Systems et al)

4. Duplicate detection • Background: • Not required in the past for BC/MC as BC/MC is not retried • Now topical since 11aa enables BC/MC retries • One proposal has it • Some proposals omit it, yet no proposal says it is not necessary • Straw-poll 1: 11aa devices shall reuse the same sequence number for retries (on transmit) and perform duplicate detection (on receive) • Y, N, A Hart et al (Cisco Systems et al)

5. Legacy compatibility • Background: • Legacy need not & may not perform duplicate detection • IP header can be used for duplicate detection, yet we build L1/L2 standards and cannot depend on a particular L3 std • This can be read as a requirement from the 802 Overview and Architecture requirements 7.3 c [The probability that an MSDU delivered at an MSAP contains an undetected error, due to operation of the MAC service provider, shall be less than 5 × 10-14 per octet of MSDU length.] • Now topical since 11aa enables BC/MC retries • One proposal has it, one proposal indicates it is required • Some proposals omit it, yet no proposal says it is not necessary • Straw-poll 2: 11aa devices shall hide retries from legacy stations • Y, N, A • Straw-poll 3: For each MRMB address, 11aa devices shall have a retry address, and retries shall be transmitted to the retry address • Y, N, More Brainstorming Required, A Hart et al (Cisco Systems et al)

6. Setting up the MRBM stream • Background: • How does a client request MC/BC retries? • IGMP snooping • Layer violation • No room for specifying a retry address • No positive request for MRMB • A2C request, C2A response combined with BA agreement (ADDMBBA) • New management frames • Not client initiated • C2A request, A2C response (ADDMRMB) • New management frames • Extra frame exchange • Straw-poll 4: Preferred method to setup a MRBM stream is: • a) IGMP snooping • b) A2C req, C2A resp combined with BA agreement req/resp (ADDMBBA) • c) C2A req, A2C resp (ADDMRMB) • d) Abstain Hart et al (Cisco Systems et al)

7. Setting up the BA agreement • Background: • Some sort of BA agreement is needed before soliciting client if & which packets are received correctly • Conventional ADDBA.request and ADDBA.response • Needs prior MRMB setup frame(s) or new versions of BAR and BA • Reuses existing 802.11 technology • A2C request, C2A response combined with BA agreement (ADDMBBA) • New management frames • Not client initiated • Straw-poll 5: Preferred method to setup some sort of a BA agreement: • a) Conventional ADDBA • b) Combined setup and ADDBA (ADDMBBA) • c) Abstain Hart et al (Cisco Systems et al)

8. Teardown • Background: • How does an AP or client quit? • Similar options to MRMB setup and BA agreement setup • DELBA then DELMBBA • LVMBBA • No strawpoll since the teardown choice should equal the setup choice but in reverse Hart et al (Cisco Systems et al)

9. Generalization of BAR, BA (1) • Background: • Need to solicit BAs and efficiently harvest BAs • Easy options on this slide • No Ack • Suitable when many clients in MC group • Reuses existing 802.11 technology • Conventional unicast BAR specifying a TID • Can efficiently harvest BAs from a few clients per data frame only • Reuses existing 802.11 technology • Need to avoid BAR to originator • Straw-poll 6: 11aa should allow these methods: • Y, N, A Hart et al (Cisco Systems et al)

10. Generalization of BAR, BA (2) • Background: • Need to solicit BAs and efficiently harvest BAs • Tougher options on this slide • MBBA Req schedules MBBA Acks from clients via AID, start offset, duration • New control frames MBBA Req and MBBA Ack • Efficient and lightweight solution • M-BlockAckReq sequences M-Block Acks from clients via receiver bitmap control and partial virtual bitmap • New control frames M-BlockAckReq and M-Block Ack • M-Block Ack durations need to be agreed upon • Efficient and lightweight solution • Conventional multicast BAR • If MC/BC, requires special back-off provision to avoid a BA storm • Extends existing 802.11 technology • BAR within PSMP • Use PSMP to schedule the BAs • Extends existing 802.11 technology • Straw-poll 7: 11aa should socialize these options with interested parties before selecting 1 or more: • Y, N, A Hart et al (Cisco Systems et al)

11. Capability signaling Some proposals have it, with little detail • Some proposals omit it, yet no proposal says it is not necessary • Straw-person proposal: • an 11aa capability bit, which indicates support for mandatory 11aa features which includes easy MRMB features: e.g. duplicate detection, sequence# preservation, MRMB and BA agreement setup/teardown, No Ack and conventional BAR/BA • an extra capability bit, which indicates support for advanced MRMB features: e.g. new control frames or MC BAR within PSMP • possibly other capability bits if further features with a HW or large SW impact are included Hart et al (Cisco Systems et al)

12. Unresolved Work (1) Power Save • Currently MC/BC appears after DTIM beacons • MC/BC buffered for n*102.4 ms hurts interactive video (e.g. telepresence) • Clients generally defer while MC/BC is being transmitted after the DTIM beacon, so too much MC/BC sent at the lowest basic rate after the DTIM hurts uplink QoS (e.g. voice) • Allow clients to request (and the AP to determine) whether MC/BC: • Appears after the DTIM beacon (as at present) • Appears at advertised, scheduled intervals (like scheduled APSD, scheduled PSMP) • At any time, so clients within that MC/BC group need to be in Continuously Awake Mode • (We could straw-poll this now) Hart et al (Cisco Systems et al)

13. Unresolved Work (2) Repair Requests (Nacks) • Repair requests are more efficient that acknowledgements when PER << 0.5 • A necessary precondition for video • Repair requests still need to be acknowledged • The efficiency gains are magnified when there are many members of a MRMB group • Repair requests are complementary to acknowledgement-based schemes • Solicit acknowledgements from some devices • Receive repair requests from others • However, as we get into the details we see • Potential for impact on legacy AP and client hardware • Potential for creating new security holes • Therefore we suggest that repair requests should be thought of as a potential complement and enhancement to acknowledgement-based schemes, requiring further work, that is unlikely to displace the acknowledgement-based schemes in near-term products • Repair requests need not delay progress on acknowledgement-based schemes Hart et al (Cisco Systems et al)