GB2527601A - Managing a multipath transmission control protocol connection - Google Patents

Abstract

In a Multipath Transmission Control Protocol (MPTCP) connection comprising subflows (eg. WiFi and 3GPP/LTE subflows to a smartphone) between a client device and a server, client preferences (eg. WiFi preferred) stored at the client device are used to modify transmission of TCP acknowledgement packets over a subflow, causing a congestion control module at the server to allocate data packets between the subflows according to the client preferences. A dummy acknowledgement eg. ACKWiFi may cause the congestion control module to increase the size of an associated congestion buffer window (WWiFi), while withholding a real acknowledgement eg. ACK3G may cause a decrease in window size. A library of modified TCP packets allows the server to determine that the client is seeking to align packet provision with its preferences.

Description

Managing a multipath transmission control protocol connection

Field

The present invention rdates to managing a multipath transmission control protocol connection.

Background

Multipath TCP (MPTCP) is an evolution of Transmission Control Protocol (TCP) standardized by the Internet Engineering Task Force (IETF) which allows the o simultaneous exploitation of multiple interfaces for a single session while maintaining the standard TCP socket API (application programming interface) of an application.

The use of multiple interfaces to generate parallel subtiows enhances resource usage and increases redundancy, thus increasing the session aggregate throughput. The use of MPTCP can also contribute to ensuring smooth handover and balancing the traffic load across multiple interfaces in a congested network. In addition to the throughput enhancement brought about by introducing MPTCP into data centres and multihomed servers, it is pardcularly useful in mobile wireless networks where mobile phones are equipped with more than one interface to connect to the Internet. A smartphone using both WiFi and a 3G/LTE mobile network is a known example. In addition to the expected gains in throughput due to the increase of the aggregate bandwidth, the MPTCP connection can improve the robustness against connection disruption due to user mobility.

Figure 1 demonstrates a sketch of the complementary processes of flow control and congestion control to determine the number of packets to be sent over each subflow which corresponds to the congestion window size of each subflow.

A flow control module 201 is responsible for estimating the receive window size W1 which indicatcs the availablc space at a rcccivcr buffcr. Thc flow control modulc 201 also notifies a congestion contro' module 202 at the server or sender 102 of the receive window size Wu1 to avoid data loss due to buffer overload. It should be noted that MPTCP maintains one window per Multipath TCP connection and not independent windows for each subflow. The receive window is shared among all subflows and the receive window size is transmitted inside the window field of the regular TCP header.

Sharing the receive window between subflows limits considerably the impact of flow control into determining data share between subflows in known systems.

The congestion control module 202 exploits the information sent by the client including the receive window size W1 and acknowledgments of both subflows ACKwiri and ACK3GILTE and estimates the round trip time of each subflow R'll'wipi, RTF3G/LTE in order to work out the congestion window for each subilow WWIFI, W3G/LTE. The congestion window may be thought of as the number of packets sent over each subflow.

As will be understood by those skilled in the art, the above concept is based on a single flow TCP (or plain TCP) on which the main task is not how to split packets between jo subflows but how many packets should be sent on the only flow initiated in standard TCP.

In fact, tip till now in MPTCP, to perform splitting, the congestion control mechanism at the server has been modified to support packet allocation between subflows. This approach has the disadvantage that the client has less power and flexibility to influence packet distribution since the congestion control is performed at the server side. For examp'e if the dient has a specific preference in terms of which interface to be used most (i.e. a preferred data distribution), the server has no knowledge of the preference prior to performing the congestion control procedure since MPTCP flow control is sending one shared receive window size value between all subflows about the available receive window at the client.

One way to overcome this issue is to exchange the required client information or preferred distribution with the server through the network. However, this approach has the disadvantage that there are limited bytes allocated for flags and control signals tinder TCP option segment which is already exhausted by introducing MPTCP protocol.

A method of managing such multipath TCP connections is required.

Summary

A first aspect of the specification provides a method of managing a muhipath transmission control protocol (TCP) connection comprising a plurafity of subflows between a server and a client device, the method comprising maintaining, at the client device, a set of client preferences associated with provision of data segments from the server to the client device over a multipath TCP connection; and modifying transmission of TCP acknowledgment packets over at least one of the plurality of subfiows from the client device to the server in accordance with the set of client preferences, and causing a congestion contr& module at the server to align provision of data segments over the multipath TCP connection with the set of client preferences.

Modifying the transmission of TCP acknowledgment packets may comprise generating and sending a dummy TCP acknowledgment packet over one of the plurality of subtiows to the server, causing the server to determine that the client has received a data segment associated with the dummy TCP acknowledgment packet over said one of the plurality of subflows.

Tn response to the server determining that the client has received a data segment associated with the dummy TCP acknowledgment message over said one of the plurality of subflows, the congestion control module may increase a congestion window associated with said one of the plurality of subflows.

Tn response to the server determining that the client has received a data segment associated with the dummy TCP acknowledgment packet over said one of the plurality of subflows, the server may rekase one or more segments stored in a server buffer.

The segment associated with the dummy TCP acknowledgment packet maybe assigned a low priority score by the client.

Modifying the transmission of TCP acknowledgment packets may comprise withholding from sending to the server an existing TCP acknowledgment packet associated with receipt of a data segment over one of the plurality of subflows, causing the server to determine that the client failed to receive the data segment over said one of the plurality of subflows.

Tn rcsponsc to thc scrvcr dctcrmining that thc clicnt failcd to rcccivc thc scgmcnt, thc congestion control module may decrease a congestion window associated with said one of the plurality of subtlows.

The method may further comprise maintaining at the server a library of modified TCP acknowledgment packets, thereby allowing the server to determine that the client is seeking to align the provision of data segments over the multipath TCP connection with the set of client preferences.

The client preference comprises a target packet data allocation for each of the plurality of subflows.

The target packet data allocation may be derived from a power consumption criterion and/or a cost criterion.

The acknowledgment packet may comprise a window advertisement.

A second aspect of the specification provides a computer readable storage medium having code stored thereon, that when executed by one or more processors, performs the method of any preceding claim.

A third aspect of the specification provides a system comprising a client device and a server interconnected over a multipath transmission control protocol (TCP) connection comprising a plurallty of subflows configured to perform the method of any preceding claim.

The phirality of subflows may comprise a WiFi subflow and a 3GPP subflow.

Brief Description of the Drawings

So that that the invention may be readily understood, embodiments thereof will be described with reference to the accompanying drawings, in which: Figure 1 is a flow diagram showing illustrating flow control and congestion control in

accordance with the prior art;

Figure 2 illustrates a multipath connection between a user device and a server; Figure 3 is a flow diagram showing iflustrating flow control and congestion control in accordance with embodiments of the invention; Figure 4 is a schematic illustration of embodiments of the invention; and Figures 5-8 are flow diagrams illustrating embodiments of the invention.

Detailed Description

In embodiments of the invention, connection similar to that shown in Figure 2 may be established. Figure 2 illustrates a system overview of a multipath transmission contro' protocol (MPTCP) connection where a client, for examp'e a mobile handset o rother user equipment 101 uploads and downloads data e.g. files, images, videos or web pages from a server or sender 102 through a WiFi path and a 3G/LTE path.

Accordingly, two subfiows, the first through a WiFi hotspot and WiFi Core and the second via Evolved TJMTS Terrestrial Radio Access Network (E-UTRAN) and a 3GPP jo Evolved Packet Core (EPC) framework comprising a serving gateway (S-GW) and a packet data node gateway (P-GW), are generated. The system may also comprise standard middleboxes such as a firewall F. An initial TCP connection may be established over the 3G/LTE path using a standard TCP SYN/ACK exchange with an additional MP CAPABLE option to determine whether the network can support MPTCP. Tf successful, a MP JOIN option maybe used to establish a subtlow over the WiFi interface with the server 102.

Alternatively, the initial TCP connection can be over the WiFi path. For example, Android operating systems can establish the primary connection over the WiFi pathway, if available, and over the cellular 3G/LTE pathway if the WiFi pathway is not available.

Since the two paths encounter different network topologies and have various middlebox constraints, the generated two subfiows exhibit different capacities and round trip times (Rfls). As part of MPTCP, an important task is to determine how much data needs to be dynamically allocated at each subflow based on network congestion status, path topologies and available space at respective sender and receiver buffers. There are two proccdurcs which work jointly to pcrform thc data allocation task in MPTCP, namely flow control performed at the cfient side (receiver) and congestion control which is performed at the server side (sender).

Figure 3 is a flow diagram illustrating one embodiment of the invention. Time is shown passing downwardly along the vertical axis. In this embodiment a modification is introduced into the MPTCP flow control mechanism in comparison to prior approaches. Figure 3 sums up the timeline diagram of this procedure in accordance with MPTCP transmission progress between a client and a server.

The introduced procedure at the flow control stage improves the client's ability to alter packet allocation between subflows according to the client's priorities without introducing extra overhead into the network or altering the MPTCP protoc& itself A MPTCP connection is established between a mobile handset (client) and a sender (server) with two activated subflows, one of the subflows through a WiFi interface and Jo another subflow is established through a cellular cfient interface (3G/LTE). The process of establishing an MPTCP connection is known in the art.

Starting from the point where in the (ki)Th packet transmission WWIFI --i) packets are sent through the WiFi subflow and W3GCk1) packets are sent through the cellular path.

Assuming an packets are received correctly, the client generates the corresponding acknowledgments ACKw and ACK3G/LTL which indicates the sequence number of the next packet to be sent through each subflow. The creation of acknowledgments in TCP connections is itself known in the art.

In the embodiments shown in Figure 3, a client preferences analyser or CPA 301 is provided in which client preferences are reviewed. Client preferences include handset interface status and any running application specific requirements. The review of client preferences may be a static procedure on which a list of preferences and their related thresholds are set permanently, for example an indication that if the remaining battery capacity is less than io% all packets should be offloaded towards the less consuming interface, for example WiFi in case of moderate file sizes transfer. The main outcome of the analysis carried out at the CPA 301 is to evaluate client preferences status and evaluate an estimation of the target packets allocation Wwwi and W7c/tm for the two subflows.

The next step uses an acknowledgment manager 302 which modifies the previously generated acknowledgment ACKwipi and ACK3G/LTE in order to cause the congestion control at the server to perform packets allocation as close as possible to the client preferred althcation WWIFI and W3GJLTE without sending explicit instructions to the server.

The acknowledgement manager 302 decides whether to modify an ackno*ledgement ACK or maintain it. Modifying an acknowkdgement of a received sequence can be performed either by replacing it with a replicate of a previously received ACK or not sending an ACK in first place (emulating a scenario where this segment is not received or is lost). The acknowledgement manager 302 is also alMe to generate an ACK of an expected but not yet received segment, for example an out of order sequence. Detailed examples of how the acknowledgement manager 302 alters ACKs are presented in below.

jo The main output of the acknowledgment manager are new subtiow acknow'edgments ACKWIF2 and ACKSG/LTh.2 which will be sent to the server to perform the congestion control accordingly. It should be noted that these new acknowledgments are a'so used to re-estimate the advertised window W1 before transmission, since the modified acknowledgment may means discarding some afready saved data and received data.

Since the higher layer (for example, the appUcation) is not aware over which subflow a particular packet was transmitted, the higher ayer needs to see a TCP ACK or Data ACK (DACK), which is derived from the subflow over which the packet was transmitted.

The acknowledgement manager 302 needs to make sure the corresponding Data Acknowledgements (DACKs) are updated accordingly, to ensure consistent ACKS reporting between subflow ACKs and Data ACKs.

The updated ACIC and advertised window Wth are then transmitted to the server.

After receiving the modified ACKs, the server then performs the congestion control based on the information generated by the acknowledgment manager and prod uces the corresponding data allocation for the next transmission. As will be understood, the congestion control module may perform congestion contro' a'gorithms to achieve this.

Wwipigc) packets are then transmitted over the W1Fi subtlow and W30(ic) packets are transmitted over the 3G subflow during the subsequent k packet transmission.

This operation continues iteratively for the (k+i); (k-i-2) ... (k÷n)th iterations until a close match to the client preferences is achieved. As will be understood, the acknowledgement manager is aware of the wh&e MPTCP congestion control operation process. The MPTCP congestion control operation includes algorithms such as slow start, congestion avoidance, fast retransmission, and fast recovery.

Figure 4 illustrates the architecture of the flow control according to one embodiment.

The block architecture of the MTCP flow control mechanism described above will now be described according to its deployment in an Android mobile phone considering two wireless network technologies: LTE (Long Term Evolution) or 4G and WLAN. As will be appreciated, the architecture maintains the regular MPTCP/TCP sockets API and o introduces the CPA and Acknowledgment Manager described above, deployed at different layers.

The CPA is deployed at an upper transport layer within the Android framework. The CPA continuously observes different LTE and WLAN interface statuses (for example, chan nd quafity, power consumption, operation mode and any App or user specific requirements such quality of service (QoS), minimum data rate, latency, data cost, data priority (importance), and any other specific client preferences. The client preferences analyzer main ontput to the transport layer is to speci' target data rate of each subflow (through advertising for example target congestion windows) and the importance of expected data segments.

The Acknowledgment Manager (ACKIV1) is based on the received control signals from the CPA. The ACKM, embedded in the Linux Kernel for more efficient operation, works out which ACKs need to be amended in order to meet client preferences as close as possible. The ACKM indirectly adjusts the congestion control decisions at the server side without altering the latter operation protocol or transmitting extra control signals over the network.

Figurc 5 illustratcs a sccnario in which thc flow control opcration will bc dcscribcd. In this scenario it is assumed that an established MPTCP connection having two subflows between a server (sender) and a client has been initiated. Tn this instance, at certain time t, during MPTCP transmission, the CPA receives a specific requirement which could, for examp'e, be power consumption warning, data cost constraint or other client preference, whereby the CPA concludes an equal offload of data packets (5o%-5o%) between the two subflows is the target operating point which will fulfil the requirements of the client preferences.

The CPA informs the Acknowledgment Manager (ACK Manager or ACKM) of the target offload percentages and the ACKM determines to amend already generated ACKs in order to cause the congestion control at the sender to modi' the data offload accordingly.

In this example, at time t the congestion window of subflow 1 is 8 segments (73% of the total data sent over the two subflows) and 3 segments are sent over subflow 2. In this example it is assumed the same maximum segment size (MSS) is used in both subflows o and that both subflows operate at congestion avoidance mode at time t.

To shift the offload share the ACKM needs to modi some of the received ACKs on subflow 1 in order to cause the congestion control to reduce the congestion window to 4 segments and at the same time maintain the second flow control operation until an increase of one segment occurs (i.e. the congestion window of second subflow becomes 4).

One possible solution is that ACKM takes advantage of the fast transmission mechanism where after three duplicate ACICs are sent over the first subflow, the congestion control moves towards fast retransmission mode where the missing segment is resent and the congestion window is dropped to half the initial congestion window after receiving the missing segment. Therefore, as can be seen in Figure 5, the ACKM maintains the ACEs of the first 4 segments and alters the last four successfully received segments. In fact, in order to emulate a scenario where the fifth segment in subflow 1 (81=12001, DS=200l) is not received the ACKM does not send anyACK of this segment, thereby pretending the segment is lost. The ACKM also alter the next three ACKs by duplicating the ACK of segment 4 which is the last maintained ACK.

Therefore, the ACEs of the last three segments will be replaced by (A1=l200l, DA=200l). The ACKM needs to make sure to modify the data acknowledgement only (DA) reported by the second subflow to ensure consistency.

When the server (sender) receives the modified ACKs from subflow iand after receiving three duplicate ACKs the sender congestion control switches to fast retransmission mode for the first subflow where fast retransmission is initiated to resend segment (S1=l200l, DS=200l). Congestion control maintains a congestion -10-avoidance mode and keeps building up the congestion window based on coup'ed congestion control described previously.

After successful reception of the retransmitted segment the congestion control reduces the congestion window of the first subflow to 4 and maintains the second subflow until it attains a congestion window of 4 segments. At that moment the flow control has obtained the target sharing percentages (50% -o%) and tries to maintain this balance through producing dummy acknowledgements whenever required.

jo As will be appreciated, some of the concerns a mobile user may have, when using MPTCP for wireless data transmissions, include: * excessive energy consumption of a mobile device due to its constraints in terms of power resources. Activating both WiFi and LTE interfaces for the same service may increase the total energy consumption compared to the case of single-path TCP where only one interface is activated.

* Another limiting factor of using both interfaces, from a user preference perspective, is the data cost. By activating MPTCP the congestion control may dynamically offload the data towards the more expensive service provider without user permission for applications or services where the user may not be willing to incur the expense.

The latter two concerns are not visible at the server side where the data oftloading occurs. By using the dummy acknowledgment method the client has greater power to control both power consumption and data cost impacts in accordance with its preferences. The introduction of the CPA and ACKM will facilitate the introduction of energy-aware or cost aware MPTCP-based content delivery schemes where more flexibility in terms of data offloading is secured at the cHent side.

Using MPTCP with sulficierif flow conftol flexibility may oiler an improved user experience and satisfaction for the foflowing reasons: From an energy efficiency perspective it is known that different interfaces use dissimilar timeouts and state machines to contr& throughput and energy consumption.

Therefore these interfaces are energy optimal in different throughput regions. The latter consideration motivates a flow switching mechanism to improve the client energy efficiency. Using simple switching between interfaces is limited by the single flow -11 -transport protocol, such as TCP which is bound to a single IF address, where switching between different flows may result in a non optimal interrupted service. Instead, the use of MPTCP-based flow switching enables seamless flow switching without interrupting active flows.

Furthermore, dropping MPTCP and maintaining a single TCP connection which may, for example, consume less power or data allowance could significantly degrade the user experience, for example by providing a discontinuous service. A user may decide to maintain the costly single connection instead but by activating MPTCP and exploiting jo all available sub-flows simultaneously a belier service may be provided. For instance, the user could be wifling to use costly subflows only to ensure continuous operation of service critical tasks (such as building up the Document Object Model (DOM) tree in browsing) and simultaneously exploit remaining less expensive low quality subflows to perform less critical tasks (such as downloading complementary images). To do the tatter the MPTCP needs to be aware about the data priority and user preferences. This requirement is met by the embodiments described herein.

Segment prioritization In addition to the flow control mechanism, namely data offload amongst subflows described above, an additional application of CPA is to provide the ACK1'vI with segment importance/priority levels. This function can be used in conjunction with other client preferences in order to either identiI the corresponding optimum data offload or completely discard low priority segments for enhanced data flow, as is the case in buffer management described in the following section.

Buffer management TIm clicnt can also scnd dummy acknowlcdgmcnts in ordcr to maintain a bcttcr buffcr loading management at the server. For example, since 3G/LTE has a longer RTI' compared to WiFi the receiver buffer may be overloaded with out of order packets where the receiver buffer cannot be emptied until these missing intermediate packets are successfully received. To avoid this situation, the ACKM may send a dummy acknowledgment of missing packets to maintain the transmission flow.

-12 -In this example it is assumed firsily that an established MPTCP transmission between a sender and client with two active subfiows, and secondly that the sender buffer size is 6 segments, each segment having a size of 1400 bytes. Figure 6 depicts an example case where the first segment sent through the first snbflow is not received while afl consecutive three segments within the first subflow and the two segments sent over the second subflow are successfully received. At this point, the sender buffer is fully loaded with the six sent segments. Consequently, though the two segments sent across the second subflow have been received and acknowledged, no more segments can be pushed through the blocked sender buffer until the first segment (of the first subflow) jo has been received. This blockage may cause a loss in the total throughput. The sender buffer cannot be emptied until the retransmitted first segment has been successfully received, which in turn is triggered after the sender has received the three duplicate ACKs generated on the first subfiow.

Figure 7 shows a flow control mechanism according to one embodiment of the invention. In this case if it is determined that the missing first segment is not important, i.e. this segment has been assigned a low priority, the sender buffer blockage can be avoided earlier. The CPA detects the segment low priority and passes that information on to the ACKM. The priority of the segment maybe determined based on knowledge of the application to which the segment relates, or by labelling segments using Multiprotoc& Labál Switching (MPLS) or using 3GPP QoS parameters. Any other segment prioritisation mechanism that is known in the art maybe employed.

The ACKM generates a dummy ACK for the lost segment, pretending it has been successfully received. The sender then empties the sender buffer. Therefore, missing low priority segments can be overlooked and discarded from the sender buffer before a blockage occurs.

control signals exchange 3° A further application of the dummy acknowledgements is to generate a sequence of dummy ACKs. A sequence of dummy ACKs may be pre-agreed between the cHent and server ends. Each sequence of dummy ACKs may then decoded by the server side once received from the client side to reflect a certain control action on top of the primary purpose of acknowledging. Advantages of this approach include the fact that numerous combinations of dummy ACKs sequence can be designed to exchange different contr& -13 -signals or actions. Thns, client preferences may be transmitted without incurring additional overheads.

Tn this embodiment, both communication ends (sender and client) are aware of the dummy acknowledgment process and hence reducing the chances of hazardous use of dummy ACEs.

To illustrate this aspect, reference is made back to Figure 5 where an aim is to achieve a ba'anced share of data load between the two subflows as dictated by the CPA.

Abstaining from sending an ACK of segment five would trigger a fast retransmission, hence wasting time. Instead, the sender (i.e. server side) can be made aware of the client preference consisting of sending four segments per subflow by transmitting a specific sequence of dummy ACKs. For instance, the ACKM maintains the ACKs of the first four segments received at the client, and generates four duplicate ACKs for the ast four received segments. The sender will therefore recognise that no segment is actually lost, since it has already received eight ACKs within the same R'll' and will conclude that a dummyACKs sequence is in generated. Figure 8 illustrates this scenario.

Tn this case, this particular sequence of dummyACKs is translated at the sender end to the action of reducing the congestion window of subflow 1 to the number of non-duplicate ACKs signals received, in this case four segments. Clearly, the advantage is that the sender is aware that all eight segments have been successfully received and there is no need to trigger a fast retransmission. Instead the congestion window of this subtlow is reduced immediately.

The skilled person will appreciate the following advantages: Embodimcnts dcscribcd hcrcin providcs flcxibility and control powcr to smartphoncs and other client devices to make decisions on aflocating transmitted packets between respective subflows to fulfil user preferences and ensure efficient use of muhiple interfaces.

Currenfly, clients may use heuristics to periodically choose the best interface, terminating existing connections and re-establishing new ones each time a switch is made. Combined with a transport protocol such as Multipath TCP the flow control mechanism of the embodiments described herein avoid the need to make snch binary decisions, bnt instead allow continuous and rapid rebalancing on short timescales as wireless conditions change based on client preferences.

The embodiments described herein do not alter MPTCP protocol and the processes are invisible to middleboxes since no new control signals or flags are generated and exchanged.

No extra overhead or control data is sent over the network.

Full contro' of the client based on its preferences with full responsibility to maintain control congestion operation optimally.

In the foregoing description reference is made to various client devices and sender or servers apparatuses. It should be borne in mind that the various components of these dements are, unless otherwise stated, of a type known in the art. Tn particular, cHent devices may be provided with one or more memories and processors to aflow them to operate in a conventional manner. Such devices may have operating systems and software installed thereon.

Additionally, such client devices may be provided with network interfaces and modems to allow them to connect to various networks such as a WiFi or LTE network described herein. Access to a cellular network maybe via an antenna or a suitable dongle.

Example client devices include smartphones, PDAs, laptops, desktop computers or any other type of suitable computing device.

It should be noted that the cellular pathway could equally be a 2G (GPRS), 3G or LTE pathway. Indeed, it should be borne in mind that the examples of cellular and WiFi pathways arc intcndcd only to bc cxcmplary and any othcr suitablc pathways could bc used instead.

Tnput and output components such as displays, touchscreens, microphones, speakers may also be provided.

While mention has been made of a single server (or sender) in the preceding embodiments, it should be borne in mind that functions described as taking place at a -15 -single server may be performed over several locations which, when considered together, may form a single server. As is known in the art, servers comprise various memories and processors that enable the server to function.

Where a particular function is described as taking place at module, it shouftl be borne in mind that this encompasses any combination of hardware, software or firmware components that perform alone or in combination the stated function of that module.

The above embodiments are to be understood as illustrative examples of o the invention. Tt is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be empthyed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims (15)

1. Claims 1. A method of managing a mu tipath transmission control protocol (TCP) connection comprising a plurality of subflows between a server and a client device, the method comprising: maintaining, at the client device, a set of client preferences associated with provision of data packets from the server to the client device over a multipath TCP connection; and modi'ing transmission of TCP acknowledgment packets over at least one of the o plurality of subflows from the client device to the server in accordance with the set of client preferences, and causing a congestion control module at the server to align provision of data packets over the multipath TCP connection with the set of client preferences.
2. 2. The method of claim 1, wherein modifying the transmission of TCP acknowledgment packets comprises generating and sending a dummy TCP acknowledgment packet over one of the phirality of subflows to the server, causing the server to determine that the client has received a data packet associated with the dummy TCP acknowledgment packet over said one of the plurality of subflows.
3. 3. The method of claim 2, wherein in response to the server determining that the client has received a data packet associated with the dummy TCP acknowledgment packet over said one of the plurality of subflows, the congestion control module increases a congestion window associated with said one of the plurality of subflows.
4. 4. The method of claim 2 or 3, wherein in response to the server determining that the client has received a data packet associated with the dummy TCP acknowledgment packet over said one of the plurality of subflows, the server releases one or more associatcd scgmcnts storcd in a scrvcr limffcr.
5. 5. The method of daim 4, wherein the packet associated with the dummy TCP acknowledgment packet is assigned a thw priority score by the client.
6. 6. The method of any preceding claim, wherein modiring the transmission of TCP acknowledgment packets comprises withholding from sending to the server an existing TCP acknowledgment packet associated with receipt of a data packet over one of the -17-pura1ity of subflows, causing the server to determine that the client failed to receive the data packet over said one of the plurality of subflows.
7. 7. The method of claim 6, wherein in response to the server determining that the client failed to receive the packet, the congestion control module decreases a congestion window associated with said one of the plurality of subflows.
8. 8. The method of any preceding claim, further comprising maintaining at the server a library of modified TCP acknowledgment packets, thereby allowing the server Jo to determine that the client is seeking to align the provision of data packets over the multipath TCP connection with the set of client preferences.
9. 9. The method of any preceding claim, wherein the client preference comprises a target packet data allocation for each of the plurality of subflows.
10. 10. The method of daim 9, wherein the target packet data allocation is derived from a power consumption criterion and/or a cost criterion.
11. 11. The method of any preceding claim, wherein the acknowledgment packet comprises a window advertisement.
12. 12. A computer readable storage medium having code stored thereon, that when executed by one or more processors, performs the method of any preceding claim.
13. 13. A system comprising a client device and a server interconnected over a multipath transmission control protocol (TCP) connection comprising a plurality of subflows configured to perform the method of any preceding claim.
14. 14. Thc systcm of claim 13, whcrcin thc plurality of subtiows compriscs a WiTh subtiow and a 3GPP stibtlow.
15. 15. A method or a storage medium a system substantially as hereinbefore described with reference to the accompanying drawings.