Buffering and Flow Control Solution for storage extension
Technical Field
The instant invention relates to error handling and flow control in a network environment and more particularly to automatic error handling and flow control through a predefined timing mechanism in a high latency Storage Area Network.
Background
As data centers grow across geographic locations, it becomes very important to deploy cost-effective storage infrastructure without sacrificing performance. Fiber channel switch vendors have come up with tape and disk acceleration solution which can improve the performance of application backup or remote mirroring across SAN islands. One of the solutions adopted by switch vendors is to introduce virtual initiators and targets at the edge of high latency network. These virtual entities spoof FCPXFERRDYIUs [Acknowledgments] and FCPRSPIUs [Response] to the participating host and target. This avoids latency associated with transfer of FCPXFERRDY from actual target to host. The existing solutions have couple of mechanisms for enforcing flow control by means of exchanging transmit window size between virtual target and virtual host. But the error handling is done at the boundary of a SCSI command, which can cause some delay due to retransmission in an I/O operation consisting of large FC exchange.
In an extended storage environment, there is a need to detect errors quickly and also recover without requiring hosts to retransmit entire I/O.
The present invention provides a novel way of detecting and resolving I/O errors in long distance storage environment.

Summary
To meet the above cited objectives the present invention provides a data communication method and system for handling errors and providing flow control in a high latency Storage Area Network.
An embodiment of the present invention provides a method and system for managing buffers in an extended storage environment using an adaptive rate limiting technique.
Another embodiment of the present invention provides a source [actual initiator port], a target [actual destination port], a virtual source [virtual initiator port] and a virtual target [virtual destination port] operating over a network environment e.g. a high latency storage area network.
The virtual source and virtual target spoof the functionally of their actual counter parts i.e. actual source and an actual target. A timing mechanism is used to automatically detect and send any missing/incorrect data to the relevant port and to avoid any buffer over flow. Various error conditions are defined and necessary corresponding corrective actions are taken to deal with each one of them.
Errors are handled between virtual source and virtual target while actual source and actual target remain transparent of the error handling mechanism and always get correct data. This further avoids unnecessary overhead like roundtrip time from actual source to actual target and vice versa.
Brief description of drawings
The present invention will now be described in detail by way of example only with reference to the following drawings.
Figure 1 illustrates a deployment scenario of the present invention.
Figure 2 illustrates a sequence diagram representing the use of FCPXFERRDY
for buffer management.

Figure 3 illustrates an exemplary sequence diagram depicting need for flow control.
Figure 4 illustrates structure of a PAUSE command..
Figure 5 illustrates structure of a RESUME command.
Figure 6 illustrates Adaptive Rate limiting using PAUSE and RESUME
Figure 7 illustrates structure of FCPXFERRDYIU used for acknowledgement
Figure 8 illustrates Error handling when intermediate FCPDATA sequence is lost
Figure 9 illustrates Error handling when last FCPDATA sequence is lost
Figure 10 illustrates Error handling when Acknowledgement is lost
Figure 11 illustrates Error handling when FCPRSP is lost.
Detailed description
The techniques described herein can be used in storage solutions developed to accelerate disk I/O or tape I/O over storage transports, such as FCIP [Fibre Channel over Internet Protocol] and FC over DWDM backbone.
Figure 1 illustrates a deployment scenario of the present invention.
Referring to figure 1 a host [101] and target [105] communicate over an extended storage network, wherein the host produces data and sends it for target to accept. In one embodiment of the present invention the underlying network is [Fibre Control Internet Protocol] and Fibre Control over DWDM backbone.
Further, a virtual host [102] and a virtual target [104] have been strategically placed, as shown in the figure 1. The virtual host [102] spoofs the functionality of the host [101] and virtual target [104] spoofs the functionality of target [105]. .
Each of these virtual ports [102] and [104] have predefined buffer storage. Further, the virtual ports [102] and [104] have knowledge of their counterpart's buffer status. At any point in data transfer, care is taken to avoid target buffer overrun. The virtual target [104] port periodically monitors buffer consumption rate and controls the sending port's data rate by using special control commands.

Before initiating a valid communication, the two FCP ports exchange a special command to discover capabilities such as target/initiator function, task retry support and REC support. This process is referred to as Discovery phase. In one embodiment of the invention the special command is PRLI ELS.
In the present invention the virtual host [102] and virtual target [104] FCP ports also exchange transfer burst size (buffer size) and number of initial buffers allocated for the data transfer.
A sample WRITE operation is herein described so as to enable a person skilled in the art to understand a sample communication scenario.
During a Write operation, the host [101] initiates the communication with a special command referred to herein as FCPCMNDIU. The FCPCMNDIU contains a WRITE CDB. The virtual host [102] port responds (instead of target [101]) with FCPXFERRDY immediately. Also, the burst size in FCP_XFER_RDY is based on buffer space available on virtual host port [102] and virtual target port [102] at that point in time. The host [101] starts sending data sequence, referred to herein as FCPDATA sequence, as soon as it receives FCPXFERRDY from virtual host port [102].
The sending side uses the buffer information exchanged during Process Login phase. It initiates a FCPWRITE and starts sending FCPDATA without waiting for FCP_XFER_RDY from the virtual target port [104]. The size of each FCP_DATA sequence is same as the buffer size negotiated during initial PRLI. The virtual host port [102] maintains status about buffer availability at target port [105]. The virtual host port [102] can continue to send FCPDATA sequences as long as virtual target port [104] has unused buffers. Upon receiving FCPDATA, the virtual target port [104] asynchronously sends FCPXFERRDY to indicate successful receipt of a data sequence. Further, the FCPXFERRDYs are sent in separate exchange. The virtual host port [102] uses acknowledgements to update the status of target port's [105] buffer availability. Thus virtual host port [102] and virtual target port [104] can participate in data transfer without the risk of buffer overrun at virtual target port [104].

In conventional FCP protocol, FCP_XFER_RDY_IU is used to permit the host to initiate data transfer. However in the present invention; FCPXFERRDYIU is used as acknowledgement to notify successful receipt of a data block [Figure 2].
Further, virtual target [104] sends acknowledgements (FCPXFERRDYs) in a different exchange than ongoing FCP write operation. The reason for this is the requirement for acknowledgements to be asynchronous to FCPDATA sequence. If FCP target [104] was to send the acknowledgements in same exchange, it needs sequence initiative to be returned by FCP initiator (virtual host) port [102] after each FCPDATA sequence, making the operation synchronous to the write operation.
When a new write operation is invoked by FCPCMNDIU, a unique command identifier is created, which will be referenced by both exchanges used for write operation and acknowledgments. This command identifier is used to bind FCPXFERRDYs to the FCPDATA sequences sent in a different exchange. The actual target (disk/tape) need not be connected directly to the virtual target port or the fabric switch hosting the virtual target port. It is sufficient to have the target device in the same fabric as virtual target port.
An exemplary response mechanism for the above described communication is mentioned herein.
The target sends FCPRSPIU to indicate the status of write operation. It encapsulates SCSI STATUS. At the end of write operation, the virtual target port [104] may decide to allocate more buffers to a particular initiator. This information is conveyed using FCPRSPIU. The virtual host port [102] can make use of these additional buffers during subsequent write operations.
In the above described communication mechanism, flow control is achieved by an Adaptive rate limiting technique.
Flow control between virtual host [102] and virtual target port [104] is needed in a scenario where the actual target (disk/tape) is slow in draining data buffers from virtual

target port [104]. The data buffers queued for the actual target [105] may be drained slowly due to various reasons; such as fabric congestion or bad performance of the actual target [105]. This can result in use of all the buffers in virtual target [104], leaving no space for additional data from virtual host port [102]. Even though the data transfer between virtual host [102] and virtual target port [104] is error-free, and the virtual host port [102] has received positive acknowledgements for all the transferred data sequences, further data transfer is not possible, because the actual target [104] is slow in draining those buffers. All the buffers at virtual target port [104] are exhausted. It is necessary to detect this condition proactively and throttle the originator of the write operation before buffers are exhausted at virtual target port [104].
This scenario is illustrated in figure-3.
For this, the virtual target port [104] periodically monitors the rate at which the data is received from the remote initiator port [102] and the rate at which the data is drained by the actual target [104] (disk/target). A smoothing logic (low-pass filter) is applied to avoid bias due to burstiness of the traffic. At any point the virtual target [104] port has the knowledge of average buffer consumption based on the receive throughput and transmit throughput. With this knowledge, the virtual target port [104] can calculate the approximate buffer consumption in subsequent intervals of time. The time interval can be based on parameters such as average input rate, average output data rate and the rate at which a single input buffer will be consumed. The virtual target port [104] also defines various levels of thresholds on buffer consumption. Various levels of thresholds can be 70%, 80% and 90% consumption of buffer space. At any instant, if the virtual target port [104] determines that buffer consumption is going to surpass the threshold in subsequent interval, it applies backpressure on the virtual host [102] port. The virtual target port [104] sends a specific control command to virtual host [102] port instructing it to slow down the transfer rate.
Similarly low threshold values are defined as percentage decrease in rate of buffer consumption after the high threshold is hit. So, if the current buffer consumption is at 90% and due to availability of more buffers, the consumption reduces to 80%, then it is assumed that low threshold level - 1 is hit, similarly low level threshold level 2 and 3 are

defined for 20% and 30% increase in available buffer space. When virtual target port [104] detects these conditions, a control command is sent so that the sending initiator port can increase the rate of data transfer/resume normal data transfer rate.
Thus, this adaptive rate limiting as suggested above ensures that initiator does not overrun the buffers at the virtual target port [104].
Further, two additional Basic Link Service commands, PAUSE and RESUME are described herein to enforce flow control.
PAUSE Basic Link Service Command
This command is used to slow down virtual host port [102] at the sending side. The structure of the PAUSE command is shown in Figure-4.
The R_CTL value used for this command is 0x87, which is reserved in FC-FS. The Parameter field represents type of PAUSE command and command identifier of the write operation
• PAUSE VALUE = 0x100 (256): This PAUSE command is sent when buffer consumption at VT port reaches 70%. This instructs virtual host port [102] (sender) to choose a random number between 1 and 256, and wait for selected amount of time interval before sending the next data sequence.
• PAUSE VALUE = 0x200 (512): This PAUSE command is sent when buffer consumption at virtual target port [104] reaches 80%. This instructs virtual host port [102] to choose a random number between 256 and 512, and wait for selected amount of time interval before sending the next data sequence.
• PAUSE VALUE = OxFFFFFFFF : This PAUSE command is sent when buffer consumption at virtual target port [104] reaches 90%, This instructs virtual host port [102] to stop sending data sequence till a RESUME command is sent.

This command is used to instruct the sending port to resume data transfer or increase the rate of data transfer. The structure of RESUME command is shown in Figure-5.
The RCTL value used for this command is 0x88, which is reserved in FC-FS. The PARAMETER field is used to represent different types of resume operations and the associated command identifier.
• RESUME VALUE = 0x100(256): This command is sent by virtual target port
[104 ]under two circumstances;
1. The previous buffer consumption was at 90% and current = 70%
2. The previous buffer consumption was at 80% and current = 70%)
This command instructs the sender port (VH) to wait for random amount of time between 1 and 256 milliseconds between each data sequence.
• RESUME VALUE = 0x200 (512): This command is sent by virtual target port [104] when the previous buffer consumption was at 90% and current buffer consumption is at 80%. The sender port waits for random amount of time between 256 and 512 milliseconds between each data sequence.
• RESUME VALUE = 0x00(0): This command is sent when buffer consumption falls below 70%, this resumes write operation without any delay between the data sequences.
The virtual target port [104] reserves some buffers as spare buffers, which are not advertised in PRLI exchange. During data transfer, if the sender port does not honor PAUSE command and all the buffers are exhausted, the additional data is stored in these spare buffers. The virtual target port [104] sends PAUSE command instead of FCP_XFER_RDY.
Figures - 6 represents the use of PAUSE and RESUME commands in a typical data flow.
Also, some of the existing FC and FCP IUs are modified to carry information related to buffer management.

PRLI - Process Login ELS
In the present invention, the PRLI ELS Command and Response embeds information about the buffer size and amount of buffers available in addition to other service parameters. This information helps the sender of the data to maintain buffer window information about the target.
FCP_CMND_IU
COMMAND REFERENCE NUMBER (CRN) field contains the command tag to be used for the current write operation. The virtual target port [104] uses this tag as identifier in acknowledgement and flow control (PAUSE/RESUME) frames.
FCP_DATA_IU
The data is transferred using FCPDATA IU. In conventional FCP protocol, the parameter field in the FC header contains "Relative Offset". This information is used to assemble the data in target buffer in case of out of order transfer. In this proposal, the parameter field is used to contain the buffer number of the target, where data contained in this sequence needs to be stored. The total size of the data contained in the FCPDATA sequence should be less than or equal to the burst size negotiated during PRLI.
FCP_XFER_RDY_IU [Figure 7]
In conventional FCP protocol, this IU is used to indicate the readiness of the target to receive data. Since the burst size and initial window size is established during PRLI exchange, FCPXFERRDY can be used as acknowledgement to notify receipt of a buffer.
The member fields of FCP_XFER_RDY IU are
• FCP_DATA_RO
Relative Offset in target buffer, for FCPDATA (being acknowledged)
• BUFFERNUM
Indicates that the data was successfully received into buffer designated by this field.
• COMMANDJTAG
Tag id of the write command to which acknowledgements are sent.
• ACKNOWLEDGEMENT FLAG

o ACK-1: The acknowledgment indicates successful receipt of buffer indicated by BUFFER_NUM.
o ACK-n: - The acknowledgement indicates successful receipt of all buffers indicated by BUFFERNUM and lower than that.
o ACK Type - Positive ACK/Negative ACK
o FCP_RSP_MISSING - This XFER_RDY is sent by FCP initiator when it does not receive FCPRSP sequence after completion of data transfer.
The structure of FCP_XFER_RDY IU is shown in Figure-7.
FCP_RSP_IU
At the end of write operation, the target FCP port may decide to allocate more buffers to a particular initiator. This information is conveyed using FCPRSPIU. In conventional FCP protocol, the first 8 bytes of FCPRSPIU is reserved. In this proposal, the reserved field is used to communicate following information
• Previously negotiated buffer count and buffer size
• Newly allocated buffer count and buffer size
Initiator uses this information for subsequent data transfers.
Detailed Error handling for long distance storage is described herein with reference to like figures.
This present invention describes a novel way of detecting and resolving I/O errors in long distance storage environment. The data transfer errors can be due to loss of following
• FCPDATA sequence
• Acknowledgement (FCPXFERRDY)
• FCP_WRITE command.
• FCPRSP sequence
FCP Data sequence [Figure 8]
Due to various error conditions some frames in an FCP_DATA sequence or entire FCP_DATA sequence can be lost. The relative position of the data sequence can be

intermediate or last sequence in the transfer. These error conditions are handled separately by target FCP port.
• Missing FCP_DATA (sequence no. = n) is not the last sequence
The target FCP port detects missing data sequence when subsequent FCPDATA (sequence = n+1) arrives at the other end of the channel. At this point, the target FCP port sends negative acknowledgement (via FCPXFERRDY). The buffer number in FCP_XFER_RDY is equal to the sequence number of the missing FCPDATA. The host FCP port upon receiving -ve ACK, can selectively retransmit only the missing FCPDATA. The error recovery is done at the sequence level, so if some frames in FCPDATA are lost, the entire FCPDATA sequence is considered to be lost. This scheme is represented in Figure-8.
• Missing FCP_DATA is the last sequence of data transfer [Figure 9]
The target FCP port has information about the total data transfer size from FCPWRITE command. If the last data sequence is lost, the target port can wait up to a pre-defined timeout value and send a negative ACK for the lost FCPDATA sequence. The host FCP port can resend only the data sequence, which is lost. This scenario of error detection and handling is depicted in Figure-9.
Missing Acknowledgement [Figure 10]
There is a possible chance that an acknowledgment (FCPXFER_RDY) is lost for a given FCPDATA sequence. In this case, the host FCP port detects the error condition by incorporating a pre-defined timeout between consecutive expected FCPXFERRDYs. So a missing FCPXFERRDY will result in timeout at the host side and result in retransmission of the FCPDATA sequence for which FCP_XFER_RDY was lost. The target FCP port detects duplicate FCPDATA sequence and discards the same. It also resends the missing FCPXFERRDY. If FCPXFERRDY for the last data sequence is lost and the host FCP port receives a FCPRSP sequence, then no error recovery is necessary as it is understood that target FCP port has correctly received all the data. The error detection and recovery is depicted in Figure-10.

Missing FCP_WRITE
The target FCP port can detect a lost WRITE command when it starts receiving FCPDATA without preceding WRITE command. In this case, the FCP target sends negative acknowledgement to the first FCPDATA sequence. Upon receiving negative ACK, the host FCP port resends FCPWRITE command as well as the first FCP_DATA sequence. The target FCP port can discard FCPDATA sequence and decode the WRITE command alone.
Missing FCP_RSP [Figure 11]
The target is supposed to send FCPRSP sequence containing SCSI status at the end of data transfer. If FCPRSP gets dropped due to some error, the FCP initiator detects timeout waiting for FCPRSP. At this instance, initiator will send FCPXFER RDY with flag set as FCP_RSP_MISSING. The FCP target will resend FCPRSP sequence to complete the data transfer. It is the responsibility of the FCP target port to preserve FCPRSP for a command until subsequent FCPCMNDIU is received or a predefined timeout value. Figure-11 depicts this scenario.

We Claim
1. A computer implemented data communication method for error handling between a virtual initiator port and a virtual destination port in a network environment ,the method comprising the steps of:
a) sending a stream of data sequence with embedded sequence numbers from the virtual initiator port towards the virtual destination port;

b) defining a timing threshold limit before which no further data sequence is sent;
c) waiting for an acknowledgment till the timing threshold limit hasn't expired and at least a predetermined number of buffer(s) are available at the virtual destination port;
d) defining error conditions based on the timing threshold limit and ;
e) taking corrective action on occurrence of defined error condition(s)
2. A method as claimed in claim 1 wherein the error condition is the loss of some or
all frames of the data sequence and the corrective action comprises the steps of:
a) detecting lost frames of data sequence at the virtual destination port using embedded sequence numbers;
b) sending a negative acknowledgment towards the virtual Initiator Port when the sequence number(s) are out of order and;
c) re-sending the entire data sequence towards the virtual destination port.
3. A method as claimed in claim 1 wherein the error condition is the loss of
acknowledgment for the data sequence and the corrective action comprises the
steps of:
a) detecting the loss of acknowledgment by the virtual initiator port when the
timing threshold limit between consecutive expected acknowledgments expires;
b) re-transmitting the entire data sequence towards the virtual destination port for which the acknowledgment was lost when the timing threshold limit expires;
c) detecting duplicate data sequence at the virtual destination port;
d) discarding the duplicate data sequence at the virtual destination port and;
e) resending the missing acknowledgment towards the virtual initiator port.
4. A method as claimed in claim 1 wherein the error condition is a missing command
that signals readiness to transfer data from the virtual initiator port and the
corrective action comprises the steps of:

a) detecting a data sequence without a preceding signal signifying readiness for transfer of data;
b) receiving said sequence on detecting the lost command ;

c) sending a negative acknowledgment towards virtual initiator port;
d) receiving the negative acknowledgment;
e) re sending the lost command and first data sequence towards the virtual destination port;

f) discarding the first data sequence and;
g) decoding the resent missing command wherein the missing command is a signal capable of signifying the readiness for initiating a write command as well as a read command.
5. A method as claimed in claim 2 wherein the error condition is a loss of
intermediary data sequence and the corrective action comprising the steps of:
a) sending negative acknowledgment towards the virtual destination port and;
b) performing error recovery at sequence level by sending entire lost data
sequence.
6. A method as claimed in claim 2 wherein the error condition is a loss of last data
sequence and the corrective action comprises the steps of:
a) waiting for the predetermined timing threshold limit by the virtual destination port for the lost data sequence;
b) sending a negative acknowledgment towards the virtual initiator port by the virtual destination port when the timing threshold limit expires and;
c) re-sending the lost data sequence by the initiator towards the virtual destination port.
7. A method as claimed in claim 3 wherein the lost acknowledgment is for the last
data sequence and , the corrective action comprises the steps of:
a) detecting that lost acknowledgment is for the last data sequence and;

b) assuming that virtual destination port has correctly received the whole data sequence upon receiving the response from virtual destination port.
8. A method as claimed in claim 1 wherein the error condition is a missing response
signifying an end of transfer of data sequence and the corrective action comprises
the steps of:
a) waiting for a response signifying the end of data transfer till the timing threshold limit expires;
b) detecting loss of the data sequence when the timing threshold limit expires;
c) re-transmitting an acknowledgment by the virtual initiator port with a flag indicating that response is missing and;
d) re-sending the missing response to complete the data transfer.
9. A method as claimed in claim 1 wherein the underlying network environment
over a long distance storage Area Network comprises of:
a) FCP [Fibre Channel Protocol for SCSI]
b) Fibre Channel over Internet Protocol (FCIP) and
c) Dense Wavelength Division Multiplexing (DWDM).

10. A method as claimed in claim 1 wherein the error handling between the virtual initiator port and the virtual destination port detects Input/Output (I/O) Errors , the error handling comprising error detection and error recovery and . the virtual destination port knows data transfer size.
11. A method as claimed in claim 1 wherein an actual initiator port and an actual destination port remain transparent to the error handling between the virtual initiator port and the virtual destination port.
12. A method as claimed in claim 3 wherein the re transmitting of the entire data sequence is by the virtual initiator port.

13. A method as claimed in claim 8 wherein the re-sending of the missing-response is by the virtual destination port.
14. A method as claimed in claim 1 further comprising a flow control mechanism between the virtual initiator port and the virtual destination port comprising the steps of:

a) monitoring rate at which the data sequence is received from the virtual initiator port and the rate at which data is drained by the actual destination port;
b) calculating approximate buffer consumption in predefined intervals of time
c) defining various levels of thresholds on buffer consumption and;
d) taking flow control action based on defined thresholds;
15. A method as claimed in claim 14 wherein the monitoring of rate, calculation of the buffer consumption and defining of thresholds and the flow control action is by the virtual destination port.
16. A method as claimed in claim 14 wherein the defined thresholds comprise:
a) high threshold values(s) as percentage increase in the rate of buffer
consumption and;
b) low threshold value(s) as percentage decrease in the rate of buffer consumption
after the high threshold is hit.
17. A method as claimed in claim 14 wherein before the buffer consumption surpasses the high threshold value, the virtual destination port sends a control command towards virtual initiator port for slowing down the sending rate and when the low threshold limit is hit, the virtual destination port sends a control command towards virtual initiator port for increasing /resuming the sending rate.
18. A data communication system for error handling, comprising:
a) an actual initiator port for initiating the transfer of data sequence;

b) an actual destination port for receiving the error -free data sequence;
c) a virtual initiator port for spoofing the actual initiator port and;
d) a virtual destination port for spoofing the actual destination port
wherein pre-defined errors condition(s) are handled by defining a timing threshold limit that facilitates automatic re-sending of missing data steam.
19. A data communication system as claimed in claim 18 wherein an acknowledgment(s) corresponding to a data stream is awaited till the threshold limit hasn't expired and at least a predetermined number of buffer(s) are available at the virtual destination port.
20. A data communication system as claimed in claim 18 wherein the error conditions
comprise:
a) loss of some or all frames of the data sequence;
b) loss of acknowledgment for the data sequence;
c) missing command that signals readiness to transfer data from the initiator
port and;
d) a missing response signifying an end of transfer of data sequence.
21. A data communication system as claimed in claim 20 wherein the loss of some or
all frames of the data sequence is corrected by the virtual destination port by sending a
negative acknowledgment towards the initiator Port when the sequence number(s) are out
of order and forcing virtual initiator port to re-send the entire data sequence towards the
destination port.
22 A data communication system as claimed in claim 20 wherein the loss of acknowledgment for the data sequence is corrected by retransmission of entire data sequence by the initiator port towards the destination port for which the acknowledgment was lost after the timing threshold limit between consecutive expected acknowledgments expires, the duplicate data sequence being detected and discarded at the destination port followed by re-sending of missing acknowledgment towards the initiator port.

23.. A data communication system as claimed in claim 20 wherein the loss of command that signals readiness to transfer of data from the initiator port is corrected by the virtual destination port by sending a negative acknowledgment towards the virtual initiator port, forcing virtual initiator port to re-send the lost command and the first data sequence towards the destination port.
24. A data communication system as claimed in claim 20 wherein a loss of response
signifying an end of transfer of data sequence is corrected by virtual initiator port through
a search for a data sequence signifying the end of data transfer till timing threshold limit
expires, retransmitting an acknowledgment by the initiator port with a flag indicating that
response is missing and forcing the virtual destination port to send a response as an
indication of a complete transfer.
25. A data communication system as claimed in claim 20 wherein the loss of acknowledgment for the last data sequence is corrected by assuming that destination port has correctly received the whole data sequence upon receiving the response from virtual destination port.
26. A data communication system as claimed in claim 14 wherein the virtual initiator port and virtual destination port operate over Fibre Channel over Internet Protocol (FCIP) and/or over Dense wavelength division multiplexing (DWDM).
27. A data communication system as claimed in claim 14 wherein the network environment is long distance Storage Area Network and associated latency overhead in the data communication system is optimized by avoiding round trip times between actual initiator port and the actual destination port.
28. A data communication system as claimed in claim 14 wherein flow control between
virtual initiator port and the virtual destination port comprises
a) the virtual destination port monitors rate at which the data is received from the remote initiator port and the rate at which data is drained by the actual destination port;

b) smoothing logic means applied to the data stream;
c) the virtual destination port calculates approximate buffer consumption in subsequent intervals of time;
d) the virtual destination port defines various levels of thresholds on buffer consumption;
e) the virtual destination port controls flow based on defined thresholds
29. A data communication system as claimed in claim 28 wherein the defined thresholds
comprise:
a) high threshold values as percentage increase in the rate of buffer consumption;
b) low threshold values as percentage decrease in the rate of buffer consumption after the high threshold is hit
wherein before the buffer consumption surpasses the high threshold value the virtual destination port sends a control command towards virtual initiator port for slowing down the sending rate and when the low threshold value is hit, the virtual destination port sends a control command towards virtual initiator port for increasing /resuming the sending rate.
30. A data communication system as claimed in claim 28 wherein the virtual initiator port
and the virtual destination port have memory thereon for temporary storage.