Retry strategies for use in a streaming environment

• US 7,370,129 B2
• Filed: 12/15/2004
• Issued: 05/06/2008
• Est. Priority Date: 12/15/2004
• Status: Expired due to Fees

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Barrett, Peter T., Green, Dustin L., Mohr, Grant D., Clifford, David C., Smith, Geoffrey R., Dodd, Michael D.
• Primary Examiner(s): Dang; Khanh
• Application Number:
  US11/012,891
• Publication Number:
  US 20060129723A1
• Time in Patent Office: 1,238 Days
• Field of Search: 710/106, 710/110, 710/17, 710/29, 710/30, 709/231, 709/232, 709/236, 714/748, 714/749
• US Class Current: 710/110
• CPC Class Codes: H04L 1/1877 for semi-reliable protocols, e.g. for less sensitive applications like streaming video buffer level management for video bitstream control arrangements H04N21/44004
• CPC Class Codes: H04L 1/1887 Scheduling and prioritising arrangements

Abstract

Strategies are described for performing retry analysis in an environment which involves the transmission of media information from a source module to a target module. In the context of the source module, the retry analysis determines whether the source module should satisfy the retry requests issued by the target module. In the context of the target module, the retry analysis determines whether the target module should generate the retry requests in the first place. Novel request reporting formats are also described. The target module performs analysis to determine what reporting format it should use to convey the retry requests to the source module.

Claims

1. A method for streaming resource information from a source module to a target module, comprising:

sending a stream of resource information from the source module to the target module;

receiving a retry request from the target module which indicates that the target module has failed to receive at least one packet within the stream of resource information, the target module being configured to pick a packet sequence length to send the retry request over, and wherein the target module is configured to pick the packet sequence length from a plurality of packet sequence lengths, each of the plurality of packet sequence lengths containing a variable numbers of packets;

applying retry analysis to determine whether to send the target module said at least one missing packet in response to the retry request, wherein the retry analysis determines whether to send said at least one missing packet by determining whether said at least one missing packet remains in a buffer maintained by the source module; and

sending the target module said at least one missing packet if the retry analysis confirms that said at least one missing packet should be sent.

2. The method of claim 1, wherein the retry analysis further determines whether to send the target module said at least one missing packet in response to the retry request by determining whether said at least one missing packet is already planned to be sent, and determining that the request is not appropriate when said at least one missing packet is already planned to be sent.

3. The method of claim 1, wherein the retry analysis further determines whether to send the target module said at least one missing packet in response to the retry request by determining whether said at least one missing packet has recently been sent via any delivery mechanism, and determining that the request is not appropriate when said at least one missing packet has recently been sent.

4. The method of claim 1, wherein the retry analysis further determines whether to send the target module said at least one missing packet in response to the retry request by determining whether said at least one missing packet can be delivered to the target module by a time that the target module is scheduled to perform some action on said at least one missing packet, and determining that the request is not appropriate when said at least one missing packet cannot be delivered by this time.

5. The method of claim 1, wherein the retry analysis further determines whether to send the target module said at least one missing packet in response to the retry request by determining whether said at least one missing packet can be delivered to the target module in a manner which does not exceed bandwidth limitations associated with a communication channel that couples the source module to the target module, and determining that the request is not appropriate when said at least one missing packet cannot be delivered according to such limitations.

6. The method of claim 1, wherein said at least one missing packet defines a hole in the stream of resource information, and wherein the retry request identifies the hole by providing information which identifies the start and end of the hole.

7. The method of claim 1, wherein said at least one missing packet defines at least one hole in the stream of resource information, and wherein the retry request identifies said at least one hole by providing information which identifies one boundary of the at least one hole in combination with a mask of defined size which describes missing packets within said at least one hole.

8. One or more machine-readable media storing machine-readable instructions that when executed implement the method of claim 1.

9. A source module including:

one or more machine-readable media storing machine-readable instructions that when executed by the source module cause the source module to implement the method of claim 1.

10. A method for receiving steaming resource information by a target module from a source module, comprising:

receiving a stream of resource information by the target module having a plurality of packets;

determining whether a of the packets within the stream of resource information is missing;

applying retry analysis to determine whether to send at least one retry request to the source module to request the source module to send said at least one missing packet, wherein the retry analysis determines whether to send the retry request for said at least one missing packet by determining whether the source module has previously indicated that it will not supply said at least one missing packet, the target module being configured to pick a packet sequence length to send the retry request over, and wherein the target module is configured to pick the packet sequence length from a plurality of packet sequence lengths, each of the plurality of packet sequence lengths containing a variable numbers of packets; and

sending the source module the retry request if the retry analysis confirms that the retry request should be sent.

11. The method of claim 10, wherein the retry analysis further determines whether to send a retry request by determining whether there has been a predetermined period of time since a prior retry request, and determining that the retry request is not appropriate when the predetermined period of time has not been reached.

12. The method of claim 10, wherein the retry analysis further determines whether to send a retry request by determining whether there has been a recent response from the source module to a prior retry request, and determining that the retry request is not appropriate when there has been such a recent response.

13. The method of claim 10, wherein the retry analysis further determines whether to send a retry request by determining whether (a) there has been a response from the source module to a prior retry request that does not pertain to an earliest expected missing packet, and (b) thereafter, a yet earlier missing packet is not received within a predetermined amount of time, and, if conditions (a) and (b) are met, determining that the retry request is appropriate for said at least one missing packet that is earlier in a sequence of packets than a packet associated with the response from the sewer module.

14. The method of claim 10, wherein the retry analysis further determines whether to send a retry request to the source module to request the source module to send said at least one missing packet by determining whether said at least one missing packet can be delivered by the source module by a time that the target module is scheduled to perform some action on said at least one missing packet, and determining that the request is not appropriate when said at least one missing packet cannot be delivered by this time.

15. The method of claim 10, wherein said at least one missing packet defines a hole in the stream of resource information, and wherein the retry request identifies the hole by providing information which identifies the start and end of the hole.

16. The method of claim 10, wherein said at least one missing packet defines at least one hole in the stream of resource information, and wherein the retry request identifies said at least one hole by providing information which identifies one boundary of said at least one hole in combination with a mask of defined size which describes missing packets within the at least one hole.

17. One or more machine-readable media storing machine-readable instructions that when executed implement the method of claim 10.

18. A target module including:

one or more machine-readable media storing machine-readable instructions that when executed by the target module cause the target module to implement the method of claim 10.