Throttling of predictive ACKs in an accelerated network communication system

• US 8,463,843 B2
• Filed: 05/29/2007
• Issued: 06/11/2013
• Est. Priority Date: 05/26/2006
• Status: Active Grant

• Current Assignee: Riverbed Technology, LLC (Riverbed Technology Incorporated)
• Original Assignee: Riverbed Technology Incorporated
• Inventors: Subbanna, Kartik, Gupta, Nitin, Kini, Adityashankar, Merugu, Shashidhar, O'Sullivan, Daniel Conor, Procter, Steven James, Keswani, Vivasvat Manohar
• Primary Examiner(s): BAROT, BHARAT
• Application Number:
  US11/754,940
• Publication Number:
  US 20080005274A1
• Time in Patent Office: 2,205 Days
• Field of Search: 709232-235, 709/238, 709202-203, 709/206, 709217-218, 709227-228
• US Class Current: 709/203
• CPC Class Codes: H04L 47/10 Flow control; Congestion control
• CPC Class Codes: H04L 47/266 Stopping or restarting the source, e.g. X-on or X-off
• CPC Class Codes: H04L 47/323 Discarding or blocking control packets, e.g. ACK packets
• CPC Class Codes: H04L 47/33 using forward notification
• CPC Class Codes: H04L 49/90 Buffering arrangements

Abstract

In a system where transactions are accelerated with asynchronous writes that require acknowledgements, with pre-acknowledging writes at a source of the writes, a destination-side transaction accelerator includes a queue for queue writes to a destination, at least some of the writes being pre-acknowledged by a source-side transaction accelerator prior to the write completing at the destination, a memory for storing a status of a destination-side queue and possibly other determinants, and logic for signaling to the source-side transaction accelerator with instructions to alter pre-acknowledgement rules to hold off on and pursue pre-acknowledgements based on the destination-side queue status. The rules can take into account adjusting the flow of pre-acknowledged requests or pre-acknowledgements at the sender-side transaction accelerator based at least on the computed logical length.

Claims

1. A method of limiting potential data loss when pre-acknowledging requests, the method comprising:

receiving a message as part of a transaction at a recipient-side transaction accelerator, the message being a message for which a sender expects an acknowledgement and for which a sender-side transaction accelerator sent a recipient acknowledgement of the transaction in advance of the recipient acknowledging the transaction;

computing a logical length for a request queue at the recipient-side transaction accelerator, the request queue for holding contents of messages not yet sent to the recipient;

smoothing the logical length to counteract variations in an actual queue length caused by message bursts received at the recipient-side transaction accelerator; and

adjusting the flow of pre-acknowledged requests or pre-acknowledgements at the sender-side transaction accelerator based at least on the computed logical length after being smoothed.

2. The method of claim 1, wherein the logical length for the request queue is based on the actual length of the request queue and a historical value of the logical length.

3. The method of claim 1, wherein the logical length for the request queue is the actual length of the request queue.

4. In a system where transactions are accelerated with asynchronous writes that require acknowledgements, with pre-acknowledging writes at a source of the writes, a destination-side transaction accelerator comprising:

a queue for queue writes to a destination;

memory for storing a status of a destination-side queue, the status comprising a logical request queue length;

logic for smoothing the logical request queue length to counteract variations in an actual queue length caused by message bursts received at the destination-side transaction accelerator; and

logic for signaling to a source-side transaction accelerator with instructions to alter pre-acknowledgement rules to hold off on and pursue pre-acknowledgements based at least on the logical request queue length after being smoothed.

5. The system of claim 4, wherein the logical request queue length is equal to the actual queue length.

6. The system of claim 4, wherein the destination is a file server and the source is a client having a file session with that file server.

7. The system of claim 4, wherein pre-acknowledgement rules include state of the source-side transaction accelerator when determining whether to pre-acknowledge writes.

8. The system of claim 4, wherein signaling is also a function of one or more of destination-side server processing, server-side LAN characteristics and/or the size of the write queue at the destination-side transaction accelerator.

9. In a system where transactions are accelerated with asynchronous writes that require acknowledgements, with pre-acknowledging writes at a source of the writes, a method comprising:

queuing pre-acknowledged write requests at a destination-side transaction accelerator;

determining a status of a destination-side queue, the status comprising a logical request queue length;

smoothing the logical request queue length to counteract variations in an actual queue length caused by message bursts received at the destination-side transaction accelerator; and

signaling to a source-side transaction accelerator with instructions to alter pre-acknowledgement rules to hold off on and pursue pre-acknowledgements based at least on the logical request queue length after being smoothed.

10. The method of claim 9, wherein when a size of the destination-side queue reaches an upper limit, the source-side transaction accelerator is signaled to stop pre-acknowledging writes and when the size of the destination-side queue reaches a lower limit, the source-side transaction accelerator is signaled to pre-acknowledge writes.

11. The method of claim 10, wherein the upper and lower limits are determined by one or more of explicit static configuration rules that can vary by network address characteristics and/or dynamic settings based on time of day or traffic characteristics.

12. The method of claim 9, wherein status of a destination-side queue is determined from one or more of predicted congestion based on the number of pending write requests at the destination-side transaction accelerator, the volume of the data being written, a limit on the volume of data allowed to be represented by pre-acknowledged writes, actual queue length, and/or a logical queue length other than actual queue length.

13. The method of claim 9, wherein status of a destination-side queue is determined from a logical queue length that is dependent on the actual queue length and one or more of queue pendency times for write requests, amount of time spent in the queue may be estimated based on characteristics of the server-side LAN, weights based on empirical observations, dynamic weights based on current network conditions and/or historical logical queue lengths.