WO2015048999A1

WO2015048999A1 - Method and proxy node for source to destination packet transfer

Info

Publication number: WO2015048999A1
Application number: PCT/EP2013/070624
Authority: WO
Inventors: Juho SNELLMAN; Luke GORRIE
Original assignee: Teclo Networks Ag
Priority date: 2013-10-03
Filing date: 2013-10-03
Publication date: 2015-04-09

Abstract

The present invention relates to a proxy node and a method in a proxy node for transferring packets from a source node to a destination node in an IP network. The method comprises capturing (210) a packet sent from the source node (40) to the destination node (20) and inspecting (220) the packet. The packet is forwarded (270) to the destination node when the inspection reveals that the packet is part of a TCP handshake (230) establishing a connection between the source node and the destination node. When the packet carries TCP payload data, the proxy node assumes responsibility (260) for delivery of the TCP payload to the destination node, wherein assuming responsibility comprises collecting (261) the TCP payload in a store-and-forward record in a TCP stack, forwarding (262) the TCP payload to the destination node by retrieving the TCP payload from the store-and forward-record in the TCP stack and removing (263) the TCP payload from the store-and-forward record upon receipt of a TCP acknowledgement packet.

Description

Method and proxy node for source to destination packet transfer TECHNICAL FIELD

The present disclosure relates to a method and proxy node for transferring packets from a source node to a destination node in an IP network. BACKGROUND

Transmission Control Protocol, TCP, is the most dominant protocol used in computer networking and on the Internet. TCP is a connection-oriented protocol, where devices at the end points, nodes, establish a connection before any data is sent. A TCP connection contains three phases: connection establishment, data transfer and connection termination.

In the connection establishment phase, or call set up phase, control data is passed between the nodes to establish a connection. The TCP protocol uses a three way handshake protocol to synchronize and to establish the connection between two nodes. The connection is initiated by a destination sending a SYN packet to the source. The source acknowledges the session initiation with a SYN-ACK packet, and the destination acknowledges this with an ACK packet. During this 3-way handshake the hosts negotiate the connection settings.

Once the connection is set up, the speed of the data transmission is controlled by three factors: the rate at which the source is willing to send data, controlled by the congestion control algorithm, the TCP window space advertised by the destination and the rate at which data appears to be getting delivered to the destination as determined by the ACK packets received at the source from the destination. The last point is largely determined by the round trip time, RTT, of the connection.

Performance enhancing proxies, PEPs, are network nodes inserted in the middle of the connection, which try to improve the performance of the connection by taking over a part of the TCP connection. The proxy can for example speed up the connection by reducing the apparent round trip time, negotiate a better set of TCP options on behalf of the endpoints, or react faster to any anomalies like packet loss.

There are two main categories of TCP PEPs: terminating PEPs and snooping PEPs. Terminating PEPs break the connection into two completely independent TCP connections, one from the destination to the PEP, and another from the PEP to the source. Following the introduction of a terminating PEP, the connection from the source node to the destination node is split in to unrelated connections which do not have any of the capabilites of a single connection from a source to the destination. The terminating node, must consequently have a capability to identify and handle all types of incoming packets, regardless of type of packet. The two single connections will use different sequence numbers, and potentially will have different TCP options. The PEP will receive packets from a host, extract any payload, generate new packets (possibly of different sizes) using that payload, and send these new packets to the receiving host. The terminating PEP is non-transparent to the connected nodes, which are only able too see their part of the connection.

Snooping PEPs function transparently. They observe the stream of TCP data packets and acknowledgements starting from the initial handshake, but don't intervene in the handshake. During TCP payload delivery, they observe the stream of TCP data packets and acknowledgements, andbuffer the data packets for a small duration. If the PEP detects an anomaly on one of the links, e.g. a packet loss, it will delay signalling the anomaly to the sender, and try to fix the problem by itself. A snooping PEP has limited capability to affect the speed of the TCP connection. At best it can react faster to problems, and sometimes hide the presence of connection anomalies from one of the endpoints. Specifically, a snooping PEP will not reduce the apparent round trip time on the connection. SUMMARY

It is an object of the present disclosure to overcome the disadvantages of prior performance enhancing proxies and to provide a non-terminating proxy that improves throughput of packets from a source node to a destination node in an IP network. In particular, it is an object of the disclosure to provide embodiments that enable increased robustness and improved throughput gains, in particular when the destination node is wireless device in a wireless access network.

This object is achieved by proxy node embodiments relating to methods, a proxy node and computer program executed in the proxy node.

An aspect of such a proxy node embodiment relates to a method in a proxy node for transferring packets from a source node to a destination node in an IP network. The method comprises capturing a packet sent from the source node to the destination node and inspecting the packet. When the inspection reveals that the packet is part of a three way TCP handshake that establishes a TCP connection between the source node and the destination node, the packet is forwarded to the destination node. When the inspection reveals that the packet carries TCP payload, the proxy node assumes the responsibility for delivering the TCP payload packet to the destination node. The assuming of responsibility for the delivery comprises collecting the TCP payload packet in a store -and -forward record in a TCP stack, forwarding the TCP payload packet to the destination node by retrieving the TCP payload packet from the store-and-forward record in the TCP stack. The TCP payload packet is removed from the store-and-forward record upon receipt of a TCP acknowledgement packet.

The disclosed method provides the advantage of enabling a transparent throughput of TCP payload packets from the source node to the destination node, whilst reducing the round trip times visible to the transport layer of the connections by latency splitting. In accordance with the method, undelivered data is moved closer to the destination node thereby reducing the effects on the source node from latency caused by packet loss in the destination node. Furthermore, the method in the proxy nodes provides for improved packet loss handling and a faster acceleration of the connection speed during a slow start phase of a TCP connection. The novel solution further provides the advantages of increased robustness and much bigger potential throughput gains, especially during the slow start phase of a TCP connection. In accordance with an aspect of the disclosure, the step of collecting the TCP payload packet comprises storing the TCP payload packet in a store-and-forward record in the TCP stack. A synthesized TCP acknowledgement packet is generated and sent to the source node.

In accordance with a further aspect of the disclosure the step of forwarding the TCP payload packet comprises retrieving TCP payload packet from the store-and-forward record and sending the TCP payload packet to the destination node.

According to yet an aspect of the disclosure, the step of removing the TCP payload packet following receipt of the TCP acknowledgment packet comprises detecting packet loss for sent TCP payload packet. When packet loss is detected, repeating the step of forwarding TCP payload packet. Otherwise obtaining the TCP acknowledgement packet from the destination node and removing the TCP payload packet from the store-and-forward record. According to a further option of the disclosure, the forwarding of the TCP payload packet further comprises amending the TCP payload packet upon retreival from the store-and- forward record in the TCP stack. In yet an option, the amending is performed for one or more header fields of the TCP packet.

According to another aspect of the disclosure a determination is made if there is a store- and-forward record for a connection from the source node to the destination node in the TCP stack and creating such a store-and-forward record when there is no previous store- and-forward record for the connection.

According to another aspect of the disclosure, the method further comprises verifying that the TCP packet is valid according to a TCP state transition diagram. When the TCP packet is not valid according to the state diagram, the store-and-forward record for the connection in the TCP stack is removed. Separate state variables are maintained for both traffic directions. According to an additional aspect of the disclosure, a store-and-forward record is created for the connection if there is no previous store-and-forward record for the connection.

According to an additional aspect of the disclosure, information stored in the store-and- forward record for the connection is updated based on information in one or more header fields of the TCP packet.

According to a further aspect of the disclosure, retrieval of a TCP payload packet from the store-and-forward record in the TCP stack includes selecting a TCP payload packet from the store-and-forward record in the TCP stack based on a selection policy of the proxy node. According to yet an aspect of the disclosure, the selection policy enables selection of a TCP payload packet independent of the order by which the TCP payload packet were stored in the store-and-forward record in the TCP stack.

Thus, the disclosure provides the advantage of allowing out of order packet sending by recording the order for sending TCP payload packet in the metadata of the packet. In accordance with a further aspect of the disclosure, the destination node is a wireless device node in a wireless access network.

It is an advantage of the disclosed method that it reduces the impact of characteristics of wireless links on the throughput in an IP network.

According to yet an aspect of the disclosure, the TCP payload packets are encapsulated as GTP packets.

It is an advantage of the solution that it is applicable to work on encapsulated packets as well as on TCP payload packets directly.

A further aspect of a proxy node embodiment relates to a proxy node for transferring packets from a source node to a destination node in an IP network. The proxy node comprises an inspection entity arranged to capture and inspect a packet sent from the source node to the destination node. A TCP payload collection entity is arranged to collect the payload packet and assume responsibility for delivering the packet to the destination node when the inspection reveals that the packet carries TCP payload. A storage entity is arranged to store captured TCP payload packet in store-and-forward records of a TCP stack. One or more timers are arranged to indicate packet loss of in-flight TCP payload packet upon time-out. A TCP payload delivery entity is arranged to generate and send a synthesized acknowledgement of TCP payload packet receipt to the source node, retrieve the TCP payload packet from the store-and-forward record in the TCP stack and sending the TCP payload packet to the destination node.

Another aspect of a proxy node embodiment relates to a computer program comprising computer program code that causes the proxy node to execute said method when run in the proxy node.

Other aspects of proxy node embodiments are consistent with the presentation in the detailed description and claims.

Benefits of the disclosed method, proxy node and computer program include latency splitting. The system cuts the apparent latency between two endpoints of a connection into two possibly unequal halves. The smaller apparent latency allows accelerating connection speed faster during the slow start phase of a TCP connection. The acceleration is based on the number of round trips, and latency splitting reduces the round trip time. It also allows the system to react faster to packet loss or changes in the connection properties.

Another benefit of the disclosure is that the endpoints are in agreement over the connection options. This means that there will never be a need to re-packetize data. This leads to better utilization of networking capacity and requires less computational power. Re-packetization can be wasteful due to the header overhead and requires copying the data to a new location at least once, often up to 3 times.

Since the endpoints agree on the connection options, store-and-forward records can be removed for idle connections without breaking the TCP connection if the connection becomes active again later. The proxy node can also be removed from the traffic path without breaking existing TCP connections.

The disclosed method, proxy node and computer program handles asymmetrically routed traffic, seeing the traffic flow in one direction but not in the other. If a SYN is not followed by a SYN-ACK, the packets for the connection will simply be forwarded. A further advantage is that out of order data can be processed by forwarding it before receiving all the preceding data. The practical benefit of doing this is that all this data can be sent to the receiver right away, which will store it and wait to receive the missing data. Without this feature the connection would stall on the proxy until the missing data was received from the sender.

A further advantage is that the speed of slow start phase can be increased. Undelivered data is moved closer to the destination, giving large speedups when the speed of a TCP transfer is limited by the destination's advertised window space, e.g. due to the destination or the source not supporting the window scaling TCP option. The proxy node can pre-fetch data from the source that is not immediately sent to the destination. When window space opens up on the destination, it's ready to be sent immediately, saving one round trip from the proxy to the source.

BRIEF DESCRIPTION OF THE DRAWINGS

The present technique will be more readily understood through the study of the following detailed description of the embodiments/aspects together with the accompanying drawings, of which:

Figure 1 schematically illustrates a schematic network configuration including the proxy node

Figure 2 a. schematically illustrates aspects of a method in a proxy node b. schematically illustrates further aspects of the method in a proxy node c. schematically illustrates further aspects of the method in a proxy node d. schematically illustrates further aspects of the method in a proxy node e. schematically illustrates further aspects of the method in a proxy node.

Figure 3 schematically illustrates a block diagram of a proxy node. Figure 4 represents a message sequence chart schematically illustrating messaging between a source node, a proxy node and a destination node

DETAILED DESCRIPTION

The general object or idea of embodiments of the present disclosure is to address at least one or some of the disadvantages with the prior art solutions described above as well as below. The various steps described below in connection with the figures should be primarily understood in a logical sense, while each step may involve the communication of one or more specific messages depending on the implementation and protocols used.

The general idea of the disclosure is to improve throughput from a source node to a destination node in an IP network, in particular in an IP network where the destination node is a wireless device. Embodiments of the present disclosure relate, in general, to the field of TCP packets. However, it must be understood that the same principles are applicable for other types of packets, e.g encapsulated packets in a radio network.

The technical solution is performance enhancing proxy implementing a transparent store- and-forward TCP policy and taking over the end-to-end responsibility for delivery of TCP data packets. It responds directly to TCP data packets by sending a synthesized ACK packet to the sender. It stores the data packet, and eventually forwards it to the recipient. If a TCP retransmission of a data packet is required, it will be done by the proxy.

Figure 1 schematically illustrates an IP network 10. The network 10 comprises a source node 40 and a destination node 20, e.g. a wireless device in a wireless access network. The network further comprises a proxy node 30 arranged between the source node 40 and the destination node 20 in the network 10.

Figures 2a to e schematically illustrate aspects of the method for transferring packets from a source node to a destination node in an IP network by means of a proxy node. In Figure 2a, a packet sent form a source node to a destination node is captured by the proxy node in step 210. The proxy node inspects 220 the packet to reveal the type of packet captured by the proxy node. Packets that do not match the inspection criteria are forwarded to the destination node. Invalid packets may be dropped. Invalid packets include packets with IP, TCP or UDP checksum mismatch, invalid recipient or other invalidity reasons. When the inspection reveals, in step 220, that the captured packet is part of a TCP handshake, the packet is forwarded, in step 270, to the destination node. When a further inspection reveals that there is a store and forward record for this connection in step 240 and that the packet includes TCP payload in step 250, the proxy node assumes responsibility for delivery of the TCP payload packet to the destination node in step 260. In contrast, if the the inspection concludes that the packet is not a TCP packet, or it is a TCP packet that's not part of a handshake but for which there is no existing store-and-forward-record, the packet is forwarded to the destination node without further actions.

When the inspection reveals that the captured packet represents a TCP packet sent during connection establishment or call set up phase for a TCP connection, e.g. a TCP SYN packet part of a three way handshake, the proxy node will form a decision on whether to create a store-and forward record for this connection. In a step 270, the TCP packet is forwarded to the destination node when the inspection reveals that the captured TCP packet represents a TCP packet sent during connection establishment for the TCP connection. Consequently, delivery of TCP packets during the connection establishment phase is unaffected by the proxy node. The decision on creating a store -and -forward record for the connection is either made on information carried in the TCP packet or on the status of the system. Circumstances may result in a decision not to create a store-and-forward record for the connection include, but are not limited to:

- a prior existence of a store-and-forward record for the connection

- the packet containing unknown TCP options - the system being under too heavy CPU load

- the system being low on memory

- the system being manually configured to work in pure forward mode and, or

- the TCP packet not matching arbitrary filtering options specified by the system administrator If a store-and-forward record for the connection is found to exists, a check is performed whether the packet is valid from the point of view of a TCP state transition diagram, e.g. after a SYN packet a SYN-ACK TCP packet is expected in the opposite direction during the connection establishment phase, or a SYN in the same direction. If the check reveals a lack of validity based on the state transition diagram, the existing store-and-forward record is removed and the proxy node forwards the TCP packet to the destination node. However, if it is found that the TCP packet is a valid TCP packet based on the TCP state diagram, it is passed to a TCP stack. Separate state variables are maintained for both traffic directions.

If the decision is made to create a store-and-forward record, the TCP SYN packet can optionally be modified. For example the solution might change the MSS TCP option or remove some undesired TCP options. Following the decision on creation of a store-and- forward record for the connection, the inspected TCP SYN packet is forwarded to the addressed destination node.

When the further inspection 220 reveals that the TCP packet carries payload data 240, the proxy node assumes the responsibility 260 for delivering the TCP packet to the destination node. According to an embodiment of the disclosure, a determination is made if there is a store-and-forward record for a connection from the source node to the destination node in the TCP stack. Figure 2b discloses aspects of the step of assuming responsibility for delivery of TCP payload packet to the destination node. The TCP payload packet is collected in the proxy node in step 261; the TCP payload packet is forwarded from the proxy node to the destination node in step 262. Finally, the TCP payload packet is removed from the proxy node following receipt of a TCP acknowledgment in the proxy node. The assuming of responsibility indicated in step 260 is terminated by the removal of the TCP payload packet from the store-and-forward record of the TCP stack.

The collecting of TCP payload packet is further elaborated in Figure 2c, which reveals storing 2611 of the TCP payload packet in the store-and-forward record in the proxy node. Optionally, the inspected TCP packet is dropped when the store-and-forward record for the connection already includes the payload data of the TCP packet. The step of collecting TCP payload packet further includes informing the source node of receipt of the TCP packet by generating a synthesized TCP acknowledgement packet 252 and sending the synthesized TCP ACK packet to the source node. According to an embodiment of the disclosure, an update of the connection information in the TCP stack is performed based on options in the header of a TCP packet in a standard manner, e.g. a RST flag will cause the removal of the store-and-forward record for the connection and any stored data, a FIN flag will cause removal of the store-and-forward record for the connection when no more data is stored by the connection; an ACK flag might signal that some amount of data was successfully delivered, whereupon the corresponding data may be removed from the store-and-forward record. Separate TCP state variables are maintained for the two traffic directions.

The proxy node could, in accordance with an embodiment of the disclosure be configured to switch the connection to pure forward mode from store-and-forward. If so, the proxy node would stop storing and acknowledging any new data sent for that connection. Once no more data is stored for the connection, the store-and-forward record is removed. Since the solution is fully transparent, the endpoints are able to continue communicating with each other even after switching to a forwarding mode. The decision to switch connections to pure forward mode might be done for example by a configuration option, e.g. stop optimizing all connections, or looking at the connection properties, e.g. lack of activity on the connection over a predetermined amount of time.

The data will be stored in a store-and-forward record unless a check reveals that the data is already stored in the store-and-forward record.

Forwarding of the TCP payload packet in step 262 to the destination node comprises retrieving in step 2622 the TCP packet from the store-and-forward record in the TCP stack and sending 2624 the TCP packet to the destination node. As further detailed in Figure 2e, the forwarding of the TCP payload packet in step 262 is repeated when packet loss is detected in step 2632. If the evaluating of delivery in step 2631 indicates successful transmission of the TCP payload packet to the destination node, a TCP acknowledgement packet is obtained in step 2633. The TCP payload packet is removed from the store-and- forward record in step 2634, following the receipt of a TCP acknowledgement packet from the destination node. In an aspect of the disclosure, a step of selecting a certain stored TCP payload packet from the store-and-forward-record is performed prior to retrieving the TCP packet from the store-and-forward record in step 2622. The selection is based on a selection policy of the proxy node. In accordance with an embodiment of a selection policy, selection is made of the first TCP packet not currently in flight. The first TCP packet is the first TCP packet according to TCP sequence number.

According to an embodiment of the selection policy, TCP packets being subject to ongoing repetitive sending to the destination node are excluded from selection, i.e., exclusion of packets that are considered to be in-flight to the destination. TCP packets are considered to be in-flight if they've been sent to the destination but haven't yet been acknowledged and aren't considered lost, e.g. due to a retransmission timeout.

However, other embodiments of the selection policy allow out-of-order selection of TCP packets. The order of sending TCP packets stored in the store-and-forward record does not need to correspond to the order in which they were received. The selection policy enables selection of TCP packets independent of the order by which the TCP packets were stored in the store-and-forward record in the TCP stack. Out of order packet sending is enabled by recording the order for sending TCP packets in the metadata of the packet. It is also possible to select and send a TCP packet even if some of the preceding TCP packets are not yet stored.

When a packet it sent out on a connection, the retransmission timer for that TCP connection half is reset.

Additionally, the order in which TCP payload packets are sent out is recorded in the metadata of the packets. This extra information is needed when packets are sent out of order. The TCP stack's packet loss detection works based on the order in which packets were sent by the proxy, not the order by sequence number.

In accordance with an embodiment of the disclosure, the TCP packet is amended in step 2623 before the data packet is sent out. The TCP packet is amended upon retrieval from the store-and-forward record in the TCP stack. Minimal changes are applied to one or more header fields of the TCP packet header. The IP "id" header field is updated only if the TCP data packet is being retransmitted. The first time the packet is forwarded the id field is left untouched. The TCP "ack seqnr" header field is updated to reflect the lowest unacknowledged sequence number as seen by the proxy at the time of the transmission. The TCP "window" header field is updated to reflect the amount of data that the proxy is willing to buffer. Originally it would have contained the amount of data that the sender is willing to receive. The IP and TCP checksum fields are incrementally updated to reflect the changes in the other headers. The sending of the TCP packet to the destination node is performed with the amended TCP packet and the TCP packet is sent without a need to re- packetize the payload data included in the TCP packet thus providing an efficient solution from a computational power perspective. As previously explained with reference to Figure 2e, the store-and-forward record for the connection is removed in step 2634 following receipt of a TCP acknowledgment packet from the destination node.

In accordance with a further aspect of the disclosure, the destination node might be a wireless device node in a wireless access network, wherein a wireless device includes any type of mobile user equipment capable of receiving TCP/IP, e.g. smart phones, tablets, personal computers, etc.

It is an advantage of the disclosed method that it reduces the impact of characteristics of wireless links on the throughput in an IP network. In an embodiment of a radio network environment, the TCP packets are encapsulated as GTP packets.

Figure 3 discloses a proxy node 30 for transferring TCP packets from a source node to a destination node in an IP network. The proxy node 30 comprises an inspection entity 31 arranged to capture and inspect a TCP packet sent from the source node to the destination node. A TCP payload collection entity 32 is arranged to collect the payload packet and assume responsibility for delivering the packet to the destination node when the inspection reveals that the packet carries TCP payload. The captured TCP payload packet is stored in store-and-forward records of a TCP stack in a storage entity 33. One or more timers 34 are arranged to indicate packet loss of TCP payload upon time-out. The TCP payload delivery entity 35 is arranged to generate and send a synthesized acknowledgement of TCP payload receipt to the source node, to retrieve the TCP payload packet from the store-and-forward record in the TCP stack and and to send the TCP payload packet to the destination node.

The TCP stack will have a number of timers for each connection, for example for standard features like retransmissions and delayed ACKs. These timers might trigger sending of packets. Another aspect of a proxy node embodiment relates to a computer program comprising computer program code that causes the proxy node to execute said method when run in the proxy node.

Figure 4 represents a message sequence chart schematically illustrating messaging between a source node, a proxy node and a destination node.

In the connection establishment phase of a TCP call flow, TCP Connection Establishment signals S41 are exchanged between the destination node 20 and the source node 40. The connection establishment is usually handled by means of a three-way handshake initiated by a synchonization signal sent by the destination node. The proxy node captures all signals sent from the destination node to the source node, but when the inspection reveals that the captured signal is a S41 TCP connection establishment signal, the signal is forwarded to the receiving source node without further processing. When the TCP connection has been established between the destination node 20 and the source node 40, transfer of the TCP Data Packet(s) S44 is initiated following an S42 http Request and a TCP acknowledgement, TCP ACK, S43 from the source. The proxy node captures and inspects the S44 TCP data packet(s) directed from the source node to the destination node. The proxy node acknowledges receipt of the S44 TCP data packet(s) to the sending source node, whereupon the packets are stored in a store-and-forward record for the connection in the proxy node. The headers of the S44 TCP data packet(s) received from the source node are amended, and upon retrieval from the store-and-forward record, the proxy node transfers S45 amended TCP data packet(s) to the receiving destination node 20. The destination node directs S47 TCP acknowledgments to the sending proxy node upon receipt of the S45 amended TCP data packet(s). The corresponding TCP data packets are removed from the store-and-forward record of the proxy node upon the S47 TCP acknowledgment.

Other aspects of proxy node embodiments are consistent with the presentation in the detailed description and claims. It is obvious to the person skilled in the art that the disclosed method, proxy node and computer program also is applicable to multiple connections in an IP network, e.g connections to multiple input and output Ethernet ports. The proxy node could be implemented using any data link layer technology.

Claims

1. Method in a proxy node (30) for transferring TCP packets from a source node to a destination node in an IP network, the method comprising:

- capturing (210) one or more packets sent from the source node (40) to the destination node (20);

- inspecting (220) each captured packet;

- forwarding (270) the packet to the destination node when the inspection reveals that the packet is part of a three way TCP handshake (230) establishing a connection between the source node and the destination node, and

- when the packet carries TCP payload data (240), assuming responsibility (260) for delivery of the TCP payload packet to the destination node, wherein assuming responsibility comprises collecting (261) the TCP payload packet in a store-and-forward record in a TCP stack, forwarding (262) the TCP payload packet to the destination node by retrieving the TCP payload packet from the store-and forward -re cord in the TCP stack and removing (263) the TCP payload packet from the store-and-forward record upon receipt of a TCP acknowledgement packet.

2. The method of claim 1, wherein the step (261) of collecting the TCP payload packet comprises:

- storing (2611) the TCP payload packet in a store-and-forward record in a TCP stack,

- generating (2612) a synthesized TCP acknowledgment packet, and

- sending (2613) the synthesized TCP acknowledgement packet to the source node.

3. The method of claim 1 or 2, wherein the step of forwarding (262) the TCP payload packet comprises:

- retrieving (2622) TCP payload packet from the store-and-forward record, and

- sending (2623) the TCP payload packet to the destination node.

4. The method of any of claims 1-3, wherein the step of removing the TCP payload packet following receipt of the TCP acknowledgment packet comprises:

- evaluating (2631) delivery of sent TCP payload packet,

- when packet loss is detected, repeating the step of forwarding (262) TCP payload packet,

- otherwise obtaining (2633) a TCP acknowledgment packet from the destination node, and

- removing (2634) the TCP payload packet from the store-and-forward record.

5. The method of claim any of the preceding claims, wherein forwarding of the TCP payload packet further comprises the step of amending (2623) the TCP paload packet upon retrieval from the store-and-forward record in the TCP stack.

6. The method of claim 5, wherein the amending is performed for one or more header fields of the TCP packet.

7. The method of any of the preceding claims, further including dropping the inspected packet when determining that the TCP payload packet is stored in a store- and-forward record in the TCP stack.

8. The method according to any of the preceding claims, further comprising creating a store-and-forward record for the connection if there is no previous store- and-forward record for the connection.

9. The method according to any of the preceding claims, further comprising verifying that the TCP payload packet is valid according to a TCP state transition diagram and removing any store-and-forward record for the connection in the TCP stack when the TCP payload packet is not valid.

10. The method according to any of the preceding claims, wherein information stored in the store-and-forward record for the connection is updated based on information in one or more header fields of the TCP payload packet.

11. The method according to any of the preceding claims, further including selecting (2621) a TCP payload packet from the store-and-forward record in the TCP stack based on a selection policy of the proxy node prior to retrieving (2622) the TCP payload packet from the store-and-forward record.

12. The method according to claim 11, wherein the selection policy enables selection of a stored TCP payload packet independent of the order by which the respective TCP payload packet was stored in a respective store-and-forward record in the TCP stack.

13. The method of any of the preceding claims, wherein the destination node is a wireless device node in a wireless access network.

14. A proxy node (30) for transferring packets from a source node to a destination nodes in an IP network, the proxy node comprising:

- an inspection entity (31) arranged to capture and inspect a packet sent from the source node to the destination node;

- a TCP payload collection entity (32), arranged to collect the payload and assume responsibility for delivering the packet to the destination node when the inspection reveals that the packet carries TCP payload;

- a storage entity (33) arranged to store captured TCP payload packet in store- and-forward records of a TCP stack; - one or more timers (34) arranged to indicate packet loss of a TCP payload packet upon time-out; and

- a TCP payload delivery entity arranged to generate and send a synthesized acknowledgment of TCP payload receipt to the source node, retrieve the TCP payload packet from the store-and-forward record in the TCP stack and sending the TCP payload packet to the destination node.

15. A computer program comprising computer program code which, when executed in the proxy node, causes the proxy node to execute the method according to claims 1-13.