Modified FCS/ARQ behaviour

1. Modified FCS/ARQ behaviour Allow the delivery of frames: with configurable retransmission policies, and in certain well defined instances, appropriately tagged frames with payload bit errors John Doe, Some Company

2. Contributors/Authors John Doe, Some Company

3. Background • Data from a 802.11n network • Motivation • Issues • Benefit/Complexity Trade-off • Conclusions Outline John Doe, Some Company

4. Background • Digital video compression techniques reduce the amount of data by • Removing redundancy • Discarding the least perceptible aspects of the image • These techniques tend to increase the likelihood of noticeable artifacts when compressed data is lost • The more you compress, the more important each bit becomes • For an enjoyable and compelling user experience, transmission system for compressed video needs a low error rate • E.g 1x10-11 BER John Doe, Some Company

5. Background • Video packets with a few bit errors in the payload are still usable • If the video decoder can conceal errors • If error correction coding has been applied • It’s better than losing the whole if it cannot be retransmitted • Discarding the video packet with bit errors would cause one or more retransmits (define a mechanism to inform the transmitter of this?) • The decoder may not be able to use the retransmitted packet (it’s arrived too late) • Retransmission may introduce unacceptable delay (video artifacts) • Retransmission of the current packet may introduce additional delay in the transmission of future packets • Multicast traffic • A lost packet will not be retransmitted Can we pass more packets with bit errors in the video payload to layers above the MAC? John Doe, Some Company

6. To Be Filled … Data from a 802.11n network John Doe, Some Company

7. Video – Effect of Lost Packet • Effect of Packet Loss on Video • A video MSDU contains 7 x 188 video octets, or 10,528 ‘video’ bits. • One packet is lost, then 10,528 bits are lost. • Examples: • TV (PAL) 750 x 560 = 420,000 pixels, Frame rate of 30 fps • TV = 12.6M Pixels/sec • SDTV at 8Mbps, then 1 bit = 12.6/8 = 1.6 pixels • Hence, if one packet is lost • 10528 bits = 16582 pixels = 16582/750 = 22 lines LOST • HD 1920 x 1080 = 2,073,600 pixels • HD = 62.2M Pixels/sec • HDTV at 20Mbps, • 1 lost packet is a minimum of 19 lines lost • Losing a minimum of 19-22 lines will definitely cause an observable video error!! • Packet Loss possible because of limit on # of re-tries. John Doe, Some Company

8. Video Errors Packet Loss 0.1% gives 44 Errors per minute John Doe, Some Company

9. Video MSDU: 7*188 = 10528 bits • 34 octets for the MAC header (802.11b) • 20 octets for the IP header (RFC 791) • 8 octets for the UDP header (RFC 768) • 12 octets for the RTP header (RFC 1889) • Total unprotected header bits are 74 * 8 = 592 bits  Probability of bit error in video payload ~95% • If the bit error is in the video payload and the application can cope with the bit error, why discard the packet? Bit Errors in a Video MSDU John Doe, Some Company

10. Concatenated Coding for VideoHigher Layer SolutionBasic Methodology • To allow video coding, MAC changes required • Might allow low packet loss over PHY c.f. zero Brian Hart’s Comment: If error on FCS, do not ACK send packet up [sounds like a layer violation? MAC reTX dependent on IP checksums?] John Doe, Some Company

11. R-S Concatenated Coding Packet Loss is the concern. Improved with retries John Doe, Some Company

12. RS Coding Theoretical Improvement 2.5 errors per hour cf 44 errors per minute FEC at Application Layer potentially offers significant improvement John Doe, Some Company

13. FEC Coding at Application Layer Looks attractive, other technologies do it. Task is to see what changes are necessary to allow it. • Headers • Encryption • Retry Mechanism • Indication that Stream is using FEC • Note: FEC in the PHY layer allows to correct bit errors in one packet. • This type of FEC does not help if the whole packet is gone • Examples: convolutional coding, RS, LDPC John Doe, Some Company

14. FEC at Application Layer • Headers • Transport Layer • LLC Header, 8 Bytes, no checksum (CRC on complete frame)Need to add a checksum? • UDP Header, 8 Bytes including checksum for complete frame“UDP Lite” has been proposed that has checksum on Header only • Network Layer • IP Header, 20 Bytes with Header Checksum • RTP Header, 12 Bytes no checksum (included in UDP checksum)Need to introduce RTP Header Checksum? • Is this out-of-scope? Must be implemented. John Doe, Some Company

15. FEC at Application Layer • Encryption • Decryption will add more errors to the data, if errors in data • Video data could/should be encrypted at the Application Layer for DRM purposes(?) • Reasonable case to send video without encryption on 802.11 • Need to ‘flag’ the video data in order to allow this in a network that is using encryption. • Allowing different encryption for different transmissions needs to be solved. John Doe, Some Company

16. FEC at Application Layer • Retry Mechanism • If FCS error, no immediate ACK is sent • Transmitter sends an immediate “Retry” • If “Headers” check out, then • ACK is sent to stop more Retries • If a retry is received with no FCS error, then this should replace previous • Otherwise proceed with first (or subsequent) and present data to Application Layer • If “Headers” do not check out, then, • Dump data and look at subsequent retries John Doe, Some Company

17. FEC at Application Layer • Need to indicate to receiver (and AP if it is transferring the stream) that “FEC Stream” is in use • Video streams should be using EDCA Admission Control or HCCA and hence should be setting up a TSPEC. • TSPEC could be used to • Request ability to send “FEC Video” • Send without encryption • IE required to indicate ability of an AP or STA to support “FEC Video” John Doe, Some Company

18. Header FCS and Payload FCS? Octets: 2               2            6        6       6          2           6        2                           0-2324   4        |< -------------------------------------- MAC Header + Headers FCS -------------------------------- >| • Potential Issues: • How would intermediate nodes treat these packets? • Deep packet inspection? • Video Payload, Intermediate Layer Header Interleaving? • Tunnelling Protocols? John Doe, Some Company

19. Bit errors in encrypted data confuses the decryption engine – decrypted data is unusable • true for all ciphers • Encrypting the packet as two sub-packets – headers and payload separately – • subject to ‘cut-n-paste’ attack • This is true even if video payload is in the clear • 802.11i architecture does not allow different traffic streams within the same link to be encrypted differently What Happens When Security is ON John Doe, Some Company

20. How would .11n aggregation be affected by this approach? [Likely need to keep the “more reliable TC” in separate aggregates] How would .11n Block ACK be affected? [Is Block ACK your friend, so you can code across multiple packets?] 802.11n Features John Doe, Some Company

21. To be filled … How would this work in a 802.11s network? John Doe, Some Company

22. If packets with error are acknowledged, how would it affect ‘back off ‘ strategies that mitigate collision errors? • Already an issue for multicast and block-ACK • [Use block ack to your advantage?] • Is there a new version of ACK that says ‘the packet was received with errors and used, so do not re-transmit’? Effect on .11e protocol John Doe, Some Company

23. How complex is this strategy? • How well does it work? In all cases? In some cases (what percentage)? • [Great questions – write a PAR so this is optional work; the determination can wait for detailed study in TG] • What is the benefit? • Bounded delay, less retransmissions, reduced network load • [One system that should be used as a point of comparison: • FCS on MAC header & scrambler seed (or on both MAC & PHY headers)] • Mandate the use of retries as a simple repetition code. If the PHY & MAC headers have good FCSs, store the bit LLRs. Next time a packet is received with the same good MAC header, combine the bit LLRs, store them, form hard decisions on the LLRs and test the payload FCS. If good, ACK; if not good, keep waiting for more retries. Discard the stored LLRs when all hope is lost (mechanism TBD)] Benefit/Complexity Analysis John Doe, Some Company

24. Digital Television delivered over satellite, cable or terrestrial [vertical app over licensed band so simple error model] Professional video distribution systems [vertical app over licensed band? so simple error model] Some IPTV systems Cellular? [vertical app over licensed band so simple error model] [802.11 is unlicensed & collisions are routine. 802.11 exists in the flexible 802 arch inside a layered system. There may be multiple unreliable links in a a row. Be careful of over-simplifying the comparison] Other Technologies exploiting this characteristic John Doe, Some Company

25. Conclusions John Doe, Some Company

26. This technique is useful, addresses all concerns and should be included in the VTS SG PAR This technique is useful, but has a lot of open issues that need to be fully understood. VTS SG needs to study this further and bring a more complete proposal This technique is not useful and needs to be removed from the VTS SG PAR Straw Poll John Doe, Some Company

27. FEC Techniques John Doe, Some Company

28. FEC Techniques • FEC in PHY layers allows to correct bit errors in one packet. • This type of FEC does not help if the whole packet is gone • Examples: convolutional coding, RS, LDPC • There is a different type of FEC, called packet-based FEC. If one or more packets are missing, they can be recovered from other packets. John Doe, Some Company

29. Packet-based FEC • Given k data packets • Generate n-k parity packets • Transmit n packets • Any subset of k correctly received packets suffices to reconstruct the data. (The exact position of missing packets is unknown.) • Very efficient for multicast. Different receivers can use different subsets of k correctly received packets to recover all packets. John Doe, Some Company

30. Relevant prior work • RTP: Transport protocol for real-time applications: IETF RFC 1889 • Source identification • Packet loss detection • Inter-media synchronization • Intra-media synchronization • RTCP: RTP plus periodic retransmission of control packets • IETF RFC 2733: An RTP Payload Format for Generic Forward Error Correction John Doe, Some Company

31. Priority Encoding Transmission • Specify different priorities for different data segments • According to assigned priority use different FEC • Early detection of packet loss is the key John Doe, Some Company