[Live-devel] Packet loss recovery implementation
smurthi3 at gatech.edu
smurthi3 at gatech.edu
Wed Jan 13 15:09:14 PST 2010
I have attempted to implement a packet loss mechanism; its description is given below. I am facing some problems with it, both in terms of testing and the logic behind the implementation. Please give me your opinions and inputs on how to make this more efficient and robust.
- Every time a packet is sent, add the packet to a database (a std::map) with sequence number as key so that in case of a packet loss, the lost packet can be identified using the sequence number and retransmitted from the database. Along with the packet, information about the retry attempts and the time it was sent is also recorded.
- The ACKs are piggybacked from the client on RTCP feedback packets. The server parses the ACK info when it parses the RTCP packet and then proceeds to the next step. Thus feedbacks are received from the client in RTCP packet intervals.
- The server receives info from the client that says which are the sequence numbers received by the client in this intermission. The server then clears those seq numbers from the data base and attempts to resend the packets that still remain in the map (subject to the condition that the number of retry attempts < 5; if the number is > 5, it erases the packet from the map).
- If the time elapsed between sending of a packet and receipt of its ACK is > threshold time (which should ideally be the RTT), then the packet is retransmitted and its retry count value incremented.
- For every packet that is received by the client, the sequence number info is parsed. Once it is checked that the packet is OK, this seq number is added to a std::vector (ackVector).
- When the next RTCP packet is built, the ackVector is added to the RTCP packet and transmitted along with it. The ackVector thus provides info about all the packets received between the previous RTCP packet and now.
- The threshold time has to ideally be the RTT. But since the time taken for the ACKs is the RTCP interval, the server is forced to keep that as the threshold value. Is there any way to work around this?
- There is considerable delay in processing the map functions at the server, I am not sure but I think this adversely affects the performance of the server. Any way I can improve this?
- My biggest issue is with testing the implementation against losses. The code provides a method to introduce losses, but this function could also drop the retransmitted packets. How do I check if the retransmissions are happening correctly?
- RFC 4588 (http://tools.ietf.org/html/rfc4588) mentions that retransmitted packets must not have the same sequence numbers as the original packets as this could corrupt the QoS statistics. In that case, how do I retransmit an old packet, but with a new sequence number? And if I don't do this, how do I make sure the QoS statistics give the correct results?
All inputs will be highly appreciated.
More information about the live-devel