Retry strategies for use in a streaming environment

• US 20060129723A1
• Filed: 12/15/2004
• Published: 06/15/2006
• Est. Priority Date: 12/15/2004
• Status: Active Grant

• 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.
• Granted Patent: US 7,370,129 B2
• Time in Patent Office: Days
• US Class Current: 710/106
• 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;

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 based on an assessment of the level of appropriateness associated with the retry request; 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 assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the particular packet remains in a buffer maintained by the source module, and determining that the request is not appropriate when the particular packet is no longer present in the buffer.

3. The method of claim 1, wherein the retry analysis assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the particular packet is already planned to be sent, and determining that the request is not appropriate when the particular packet is already planned to be sent.

4. The method of claim 1, wherein the retry analysis assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the particular packet has recently been sent via any delivery mechanism, and determining that the request is not appropriate when the particular packet has recently been sent.

5. The method of claim 1, wherein the retry analysis assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the particular packet can be delivered to the target module by a time that the target module is scheduled to perform some action on the particular packet, and determining that the request is not appropriate when the particular packet cannot be delivered by this time.

6. The method of claim 1, wherein the retry analysis assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the particular 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 the particular packet cannot be delivered according to such limitations.

10. 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.

11. 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.

15. One or more machine-readable media containing machine readable instructions for implementing the method of claim 1.

16. A source module including logic configured to implement the method of claim 1.

7. (canceled)

8. (canceled)

9. (canceled)

12. (canceled)

13. (canceled)

14. (canceled)

17. A method for receiving streaming 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 at least one of the packets within the stream of resource information is missing;

applying retry analysis to determine whether to send a 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 based on an assessment of the level of appropriateness associated with the retry request; and

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

18. The method of claim 17, wherein the retry analysis assesses the level of appropriateness associated with the 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.

19. The method of claim 17, wherein the retry analysis assesses the level of appropriateness associated with the 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.

20. The method of claim 17, wherein the retry analysis assesses the level of appropriateness associated with the 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 at least one particular missing packet that is earlier in a sequence of packets than a packet associated with the response from the server module.

21. The method of claim 17, wherein the retry analysis assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the source module has previously indicated that it will not supply the particular packet, and determining that the retry request is not appropriate when the source module has made such a previous indication.

22. The method of claim 17, wherein the retry analysis assesses the level of appropriateness associated with the retry request for a particular packet in said at least one missing packet by determining whether the particular missing packet can be delivered by the source module by a time that the target module is scheduled to perform some action on the particular packet, and determining that the request is not appropriate when the particular packet cannot be delivered by this time.

26. The method of claim 17, 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.

27. The method of claim 17, 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.

32. One or more machine-readable media containing machine readable instructions for implementing the method of claim 17.

33. A target module including logic configured to implement the method of claim 17.

23. (canceled)

24. (canceled)

25. (canceled)

28. (canceled)

29. (canceled)

30. (canceled)

31. (canceled)