GB2525416A

GB2525416A - Data Transfer using a multipath TCP Connection

Info

Publication number: GB2525416A
Application number: GB1407227.6A
Authority: GB
Inventors: Mahmoud Hadef; Howard Peter Benn
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2014-04-24
Filing date: 2014-04-24
Publication date: 2015-10-28
Anticipated expiration: 2034-04-24
Also published as: GB201407227D0; GB2525416B; KR20150123185A; KR102328615B1

Abstract

A method of transferring data between a first device 300 and a second device 302 using a Multipath Transmission Control Protocol (MPTCP) connection. The method includes receiving data to be transferred, the data comprising a set of data units and extracting (304) priority-related information for the data units from the received data. The method further includes processing (304, 306, 310) the priority-related information in order to allocate each said data unit to one of a plurality of subflows of the MPTCP connection, and transferring (310) the data units to the second device over the MPTCP connection using the allocated subflows. Data units assigned to one of a plurality of priority levels may be assigned to one of a plurality of quality classes of subflows. Further the data units may be reordered in the buffer 308 according to the determined priority of the data units, possibly using forward and backward loading of low and high priority data units. The extracting/analysing 304 of the data units may comprise extracting cross layer information, such as priority information from the session layer. High priority levels may be assigned to video I-frames, SPDY SYN_STREAM or SYN_REPLY units, based on order of units or based on explicit priority flags, for example.

Description

Data Transfer Using a Multipath TCP Connection The present invention relates to data transfer using a Multipath TCP (MPTCP) connection.

MPTCP is an evolution of the Transmission Control Protocol (TCP) standardized by the Internet Engineering Task Force that allows the simultaneous exploitation of multiple interfaces for a single session while maintaining the standard TCP socket Application Programming Interface (API) to the application. The use of multiple interfaces to generate parallel subflows can enhance resource usage and increase redundancy, thereby increasing the session aggregate throughput. It can also contribute towards ensuring smooth handover and balancing of the traffic load across multiple interfaces in a congested network. In addition to the throughput enhancement brought by introducing MPTCP into data centres and multihomed servers, MPTCP is particularly useful in mobile wireless networks where mobile phones are equipped with more than one interface to conned to Internet. Using both Wi-FiTM and a mobile network 3GILTE (Long Term Evolution) is a typical use case. In addition to the expected gains in throughput due to the increase of the aggregate bandwidth, MPTCP can improve robustness against connection disruption due to user mobility.

Figure 1 illustrates a system overview of an example MPTCP connection where the client 100 (mobile handset UE) uploads data e.g. files, images, videos or web pages from the server 102 AS through two interfaces Wi-FiTM 104 and 3G/LTE modem 106. Accordingly, two subflows, one through WiFiTM hotspot and a second via E-UTRAN, are generated. As the two paths encounter different network topologies and go through various middlebox constraints, the generated two subflows exhibit different capacities and Round Trip Times (RTT5).

MPTCP's critical tasks include how to work out how much data need to be allocated at each subflow based on network congestion status, paths topologies and receiver buffer available space.

In some applications and services, such as SPDYTM, the data segments are prioritized in a manner where higher priority data is to be sent first in order to enhance browsing experience. Pushing prioritized data into an MPTCP buffer where MPTCP is not aware of a segment's importance and significance may render the transmission less efficient, especially if some of the high importance segments are sent through a lossy channel, where recursive retransmission may occur in order to successfully transmit the high importance data (such as the HTML file required to construct the Document Object Model (DOM) in browsing).

For more efficient transmission it would be beneficial for MPTCP to be aware of the importance of packets so that congestion control can push the high priority packets into robust, less lossy subflows. To the best knowledge of the present inventors, no previous work in literature has addressed this cross layer operation and how MPTCP can classify subflows and offload the prioritized data into those subflows.

Embodiments of the present invention are intended to address at least some of the problems discussed above. Embodiments of the present invention can provide a mechanism for MPTCP-based data transfer systems to classify available subflows in order to reflect exchanged prioritized packets from the session layer. Embodiments can also manage the common buffer to offload the prioritized data into appropriate subflows.

According to a first aspect of the present invention there is provided a method of transferring data between a first device and a second device using a Multipath Transmission Control Protocol (MPTCP) connection, the method including: receiving data to be transferred, in use, from the first device, the data comprising a set of data units; extracting priority-related information for the data units from the received data; processing the priority-related information in order to allocate each said data unit to one of a plurality of subflows of the MPTCF connection, and transferring the data units, in use, to the second device over the MPTCP connection using the allocated subflows.

The step of processing the priority-related information may comprise analysing the data units in order to assign one of a plurality of priority levels to each said data unit.

The method may further include analysing the subflows of the MFTCP connection in order to assign one of a plurality of quality classes to each said subfiow.

The step of processing the priority-related information may further comprise allocating the data units to the subflows so that the data units having a particular said priority level are allocated to a said subflow having a particular said quality class.

The method may further include applying a congestion control process to each said subflow of the data units transferred from the buffer. The congestion control process may comprise a coupled MPTCP congestion control mechanism.

The step processing the priority-related information may include classifying the subflows into the quality classes, e.g. low and high, based on at least one data transfer quality-related factor of the subflows, such as loss rate and/or other parameters, such RIT and ACKs. A said subflow having a high said quality class may comprise a said subflow that is robust (e.g. having an expected low retransmission rate) and not lossy. A said subflow having a having a low said quality class may comprise a said subflow that does not require recursive retransmission of the data units.

The step of processing the priority-related information may include calculating a loss rate of a said subflow and assigning a said quality class to the subflow based on the calculated loss rate. The calculating of the loss rate of a said subflow may include: transferring a number of data units using each said subflow; observing a number of lost data units (e.g. non-acknowledged (NACK) data units) within a time window (T) for each said subflow; and calculating an average, Loss Rate (LR1) within the time window for each said subflow.

The calculating of the average Loss Rate LR1 may use an equation: LR = ET NACK1/ ET W The step of classifying the subflows into the quality classes may include ordering the subflows based on the calculated average Loss Rate LR of each said subflow. In some embodiments, any said subflow that has a said calculated average Loss Rate LR1 less than a reference value, e.g. 1%, is classified as a high said quality class subflow.

The step of analysing the subflows may include: calculating an expected delivery time to deliver a number of high said priority level said data units via a plurality of combinations of subgroups of the subflows, and classifying the subflows in a said subgroup with a lowest said expected delivery time as high said quality class.

The step of calculating the expected time may include: attempting delivery of the number of the data units through a said subgroup of the subflows; performing recursive transmission of the number of the data units, and calculating a corresponding window for each said subflow at each Round Trip Time (RTT).

The step of analysing the subflows may be performed dynamically, e.g. in response to a condition of a network used for the MPTCP connection changing.

The step of analysing the data units may include extracting priority-related information for the data units from the received data. The step of extracting priority-related information may process cross layer information, such as information about data units crossing between session layer and transport layer. The step of analysing the data units may include analysing priority flagslsignals of the data units. In some embodiments, the step of analysing the data units includes analysing relevance order of the data units.

A said data unit may comprise a SPDYTM message. The step of analysing the data units may include assigning a high said priority level to a said data unit comprising a said SPDYTM message having a SYN_STREAM or SYN_REFLY high priority identifier.

The data may comprise video data wherein each said data unit is categorised as an I-frame, a P-frame or a B-frame. The step of analysing the data units may include assigning a high said priority level to a said data unit comprising an I-frame and assigning a low said priority level to a said data unit comprising a said F-frame or a said B-frame.

The step of arranging the data units in the buffer may include forward loading the data units having a high said priority level into the buffer and backward loading the data units having a low said priority level into the buffer. The step of arranging the data units in the buffer may include preventing loading of further said data units having a low said priority level into the buffer when remaining space in the buffer is only sufficient for loading of said data units having a high said priority level.

The MPTCP connection may use a plurality of communications network interfaces. The communications networks may comprise wireless networks, e.g. LTE and WiFiTM. The method may include establishing an MFTCP connection between the first device and the second device. The MFTCP connection may include a plurality, e.g. two, of subflows.

According to another aspect of the present invention there is provided a system for transferring data between a first device and a second device over a Multipath Transmission Control Protocol (MPTCP) connection, the system including: a device configured to receive data to be transferred, in use, from the first device, the data comprising a set of data units; an analyser (304) configured to extract priority-related information for the data units from the received data; a processing device (306, 310) configured to process the priority-related information in order to allocate each said data unit to one of a plurality of subflows of the MPTCP connection, and a data transfer device configured to transfer (310) the data units, in use, to the second device over the MPTCP connection using the allocated subflows.

The analyser (304) may be logically located within an AndroidTM framework and the processing device (306, 310) may be logically located within a Linux kernel.

The MPTCP connection can use at least one wireless network, e.g. a 3G/LTE orWiFiTM network.

According to another aspect of the present invention there is provided computer readable medium storing a computer program to operate a method substantially as described herein.

According to yet another aspect of the present invention there is provided a method of transferring data between a first device and a second device using an MPTCP connection, the method including: receiving data to be transferred, in use, from the first device, the data comprising a set of data units; analysing the data units in order to assign one of a plurality of priority levels to each said data unit; analysing subflows of the MPTCP connection in order to assign one of a plurality of quality classes to each said subflow; allocating the data units to the subflows so that the data units having a particular said priority level are allocated to a said subflow having a corresponding said quality class; arranging the data units within a buffer of the MPTCP connection in accordance with the assigned priority levels of the data units; transferring the arranged data units from the buffer, in use, to the second device using the allocated subflows.

The step of processing the priority-related information may include: determining from the priority-related information whether a said data unit has a low priority level or a high priority level; allocating a said data unit having a said low priority level to a said subflow having a high quality data transfer classification, and allocating a said data unit having a said high priority level to a said subflow having a having a low quality data transfer classification.

The method may further include classifying the subflows of the MPTCP connection as a said subflow having a having a high quality data transfer classification, or as a said subflow having a having a low quality data transfer classification.

According to the present invention, there is provided a method, an apparatus and a system as set forth in the appended claims. Other features of the invention will be apparent form the dependent claims, and the description which follows.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example, to the accompanying diagrammatic drawings in which: Figure 1 illustrates a system overview of an example MPTCP connection being used to transfer data from a server to a client; Figure 2 is a timeline diagram illustrating data transfer from a server to a client over an MPTCP connection in accordance with an embodiment of the data transfer method the present invention; Figure 3 illustrates architecture of an example MPTCF prioritized data offload mechanism deployed in a mobile device in accordance with an embodiment of the data transfer method; Figure 4 graphically illustrates buffer management in accordance with an embodiment of the data transfer method, and Figure 5 graphically illustrates importance categorization of video frames in accordance with an embodiment of the data transfer method.

Embodiments of the present invention introduce new procedures into the MPTCP offloading mechanism that can include packet/segment analyser 304, subflow coordinator 306, buffer manager 308 and dual congestion control 310. Figure 2 is a timeline diagram of the introduced procedures in accordance with MPTCP transmission progress between a server 300 and a client 302. It will be appreciated that the steps of Figure 2 are exemplary only and in alternative embodiments at least some of the steps may be re-ordered or omitted and/or additional steps could also be performed.

The procedure assumes that a MTCP connection is established between a mobile handset (client 302) and a sender (server 300) with multiple activated subflows. Starting from the point where cross layer information exchange occurs between session layer and transport layer to inform the MPTCP regarding the prioritization level of the packets/segments and which of those correspond to high priority critical tasks (for example, segments relating to constructing DOM in browsing, or I-frames in video transmission, although it will be understood that the method can be applied to other types of data units that may be prioritised in different ways). The Packet Analyzer (PA 304) classifies the segments/packets into priority level classes. In the example embodiment, the classes comprise a high priority class (HPC) and a low priority class (LPC) based on the exchanged information (segment's priority assuming SPDYTM service, for example). However, it will be understood that in alternative embodiments, different types and/or number of priority level classes may be used.

Meanwhile, the Subflow Coordinator (SC 306) classifies the available subflows into quality classes based on data transfer quality factors, such as their loss rate and/or other parameters, such as RTTand/orACKs. Examples of the classification procedures that can be performed by the SC are described below. The classification is performed dynamically and allow continuous and rapid rebalancing on short timescales as, for example: network/wireless conditions changing based on client preferences. In the example embodiment, two quality classes of subflows are provided. The subflow classes are then mapped to the HPC and LPC

B

segments/packets performed by the PA 304. An example mechanism for performing the classification will be described below. In alternative embodiments, different types and/or number of quality classes may be used. The data unit priority level classes, the subflow quality classes and/or the number of network interfaces involved in the MPTCP connection do not necessarily correspond to each other.

After working out aggregate available subflow windows for each class, which can involve allocating a particular number of high priority packets and a particular number of low priority packets to include in each window, the Buffer Manager (BM 308) reorders the classified packets within the common buffer of the server 300 so that the available buffer space can be allocated for both HPC and LPC segments/packets in a fair and opportunistic manner for better buffer usage efficiency. An example of this allocation will be described below.

Finally, two separate congestion controls 310 can be applied to each quality class described above and allocate the packets to the subflows according to classifications computed. Each congestion control process can be a basic coupled MPTCP congestion control mechanism, although the two controls are not explicitly coupled and operate independently. However, as subflow classification is dynamic, subflows can be reassigned to different subflow regularly which ensures sort of indirect coupling between the two mechanisms.

In order for the data to be transferred from the server 300 to the client 302, the packets are transferred to a flow controller 312 of the client device, which indicates to the server whether space is available on the buffer of the client device to receive the data.

Block architecture of an example MPTCP flow control mechanism and its deployment in an AndroidTM mobile phone is illustrated in Figure 3. It is implemented using two wireless network technologies: LTE and Wireless Local Area Network (WLAN). The architecture maintains the regular MPTCPITCP sockets API 501 (assuming an established MPTCP connection between the server/sender and the client where two subflows are already initiated) and introduces the packet analyzer (PA) 304 and the subflow coordinator (SC) 306, described below, deployed at different layers, but uses a cross layer channel between the session and transport layers to exchange prioritization control signals. It will be understood that in other embodiments, othertypes of networks, interfaces and sending/receiving devices can be used.

The packet analyzer (PA 304) is introduced at the interface between the session/application layer 502 and transport layer (and so is logically located within the AndroidTM framework in the illustrated embodiment). Data relating to the priority levels of data units to be transferred is received and processed by the PA 304. An important role of the packet analyzer is to classify packets (e.g. as high priority class (HPC) and low priority class (LPC)) based on the exchanged packets' priority flags/signals. For instance, in the case of SPDYTM service the PA looks at the either grouping flags of segments or relevance order before classifying the segments.

The subflow coordinator (SC) 306 and the buffer manager (BM) 308 are, together with the MPTCP connection 504, TCPs SOSA, SOSB and IP routing component 506, logically located within the LinuxTM kernel in the illustrated embodiment. The SC 306 dynamically classifies the available subflows (508A, 508B in the example) into quality classes, e.g. HPC and LPC, based on quality-related factors, such as their loss rate and/or other parameters, such RTT and ACKs. In other embodiments, data from the flow control window may be used to allocate quality classes, and, in general, any information exchanged during transmission could from the basis of the classification. It will also be understood that different mechanisms can be used to perform the classification process.

A first example classification process is a simple one based on calculating the loss rate of each subflow. With this example classification procedure, at the start all subflows, say i=1:N subflows, are classified by the SC 306 as the HPC class. The SC 306 then observes the number of lost packets (non-acknowledged NACK packets) within a certain time window T; typically few RTTs for each subflow and then calculates the average Loss Rate LR1 within this time window: LR = ET NACK1/ ET W1 After calculating all LR i=1:N, the SC 306 orders all the subflows based on their estimated loss rates. Basically, any subflow which fulfils LRI<LRrQ1 is classified as HPC and any subflow that does not meet that condition is assigned to the LPC class. A typical example value of is 1%.

Another more complex, but more efficient, example of a classification procedure that can be performed by the SC 306 is based on calculating the expected time to deliver high priority M packets of all possible subgroups of subflows. For each subflow, the SC 306 assumes that it tries to deliver M packets through the subgroup of subflows starting from the actual status/current state of the MPTCP congestion control mechanism and then operates recursive transmission of the packets and calculates the corresponding window for each subflow at each RU based known congestion control algorithms.

In one embodiment the buffer manager BM 308 allocates the classified packets into the common buffer such that HPC packets are located, starting from the beginning of the common buffer and are loaded, for example, from left to right (forward loading) and LPC packets are loaded from right to left, starting from the end. It will be appreciated that this is only one possible buffer management example and other sharing mechanisms can be used. Figure 4 graphically illustrates buffer management in accordance with this method. One important aspect is that HPC data can always have priority in the case of a loaded buffer where no further loading of LPC is performed if the available memory space if required for HPC transmission.

An alternative embodiment is configured to process SPDYTM segments. SPDYTM breaks down H1TP communication into small individual frames, which map to messages within a logical stream. The stream is a virtual channel which carries bidirectional messages. Each stream has a unique integer identifier (1, 2 S). Unlike HTTP 1.x, in SPDYTM all communication is performed within a single TCP connection. In order to further improve the performance of SPDYTM each stream is assigned a 31-bit priority value: 0 represents the highest priority stream.

* 2 31 represents the lowest priority stream.

As not all resources have equal priority when rendering a page in the browser, the HTML document itself is critical for construction of the DOM: the Cascading Style Sheets (CSS) is required to construct the CSS Object Model; both DOM and CSS Object Model construction can be blocked on JavascriptTM resources, and other resources, such as images, are often fetched with lower priority. With priorities in place, the client and server can apply diverse techniques to process individual streams, messages, and frames in an optimal order by controlling the allocation of resources (CPU, memory, bandwidth), and once the response data is available, prioritize delivery of high-priority frames to the client.

However, SPDYTM is designed to fetch all segments into one TCP connection and is not designed for MPTCP. Implementing SPDYTM on top of basic MPTCP would not be optimal because mapping prioritized segments into more than one TCP subflow is not considered.

However, the present inventors have developed an embodiment of the mechanism described herein to provide enhanced mapping that can enhance SPDYTM performance further by ensuring high priority are sent over the best set of subflows as soon as possible, and allocating the low priority segments to lossy subflows.

Priority identifiers such as SYN_STREAM and SYN_REPLY in SPDYTM messages can be exchanged with the MPTCP packet analyzer 304 in order to classify priority level of the segments. The procedure described above can then be followed to complete the classification process.

Another embodiment can classify video packets based on their priority. Video content is differentiated from regular data as encoded video packets are temporally correlated with previously encoded video packets, which introduces interdependencies amongst packets.

Moreover, video packets are classified in three major categories according to their ability to be self-decodable or dependent-decodable. Video packets/frames are discriminated in three categories: I-frames, P-frames and B-frames, in particular: -I-frames are the least compressible frames and do not depend on other video frames to be decoded -P-frames require data from previous frames in order to be decoded and can achieve better compression than I-frames -B-frames use post and previous frames for encoding in order to achieve a higher level of compression, but their decoding process strictly depends on the success of the decoding of the packets upon which they depend Considering this categorization, the present inventors have devised a prioritisation (illustrated in Figure 5) for the frames based on their independency and self-decoding ability as more, or less important: -I-frames can be considered more important than P or B frames because they are self-decodable and do not require any reference frame. P and B frames need I-frames in order to be decoded -P-frames can be considered more important than B-frames, because they require prior successful decoding of the reference frame/packet in order to be decoded themselves.

Moreover, P-frames can be used as a reference frame for the encoding of B-frames and so B-frames depend on the P-frames, if they refer to them -B-frames can be considered the less important than P4rames or I-frames (in terms of self-decoding ability) because they require prior successful decoding of their reference frames (which may be I-frames or P-frames) for their own decoding By exchanging video frame type and importance level (for example, in one embodiment only I-frames are considered as critical and high priority, and both B-frames and P-frames as low priority) with the MPTCP packet analyzer 304, the PA can classify the corresponding frames into HPC or LHC classes. The process described above can then be followed to complete the transmission process.

Embodiments of the present invention can provide an efficient MPTCP transmission scheme where the priorities of data units, such as packets, to be sent are reflected in the offload mechanism for a more optimized service. Extra flexibility in the MPTCP offloading mechanism can fulfil higher layers' preferences, which can be achieved by introducing the cross layer visibility.

Currently, clients may use heuristics to periodically choose the best interface, terminating existing connections and re-establishing new ones each time a switch is made.

Embodiments of the MPTCP Prioritized Data Offloading Mechanism described herein can avoid the need to make such binary decisions and instead allow continuous and rapid rebalancing on short timescales as wireless conditions change based on client preferences.

Embodiments do not alter the MPTCP transmission protocol and can be completely invisible to middleboxes as no new control signals or flags have to be generated and exchanged. Further, no extra overhead or control data will need to be sent over the network as only cross layer information is exchanged.

It is understood that according to an exemplary embodiment, a computer readable medium storing a computer program to operate a method according to the foregoing embodiments is provided.

Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), orto any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

CLAIMS1. A method of transferring data between a first device (300) and a second device (302) using a Multipath Transmission Control Protocol (MPTCP) connection, the method including: receiving data to be transferred, in use, from the first device, the data comprising a set of data units; extracting (304) priority-related information forthe data units from the received data; processing (304, 306, 310) the priority-related information in order to allocate each said data unit to one of a plurality of subflows of the MPTCP connection, and transferring (310) the data units, in use, to the second device over the MPTCP connection using the allocated subflows.
2. A method according to claim 1, wherein the step of processing the priority-related information comprises analysing (304) the data units in order to assign one of a plurality of priority levels to each said data unit.
3. A method according to claim 2, further including analysing (306) the subflows of the MPTCP connection in order to assign one of a plurality of quality classes to each said subflow.
4. A method according to claim 3, wherein the step of processing the priority-related information includes allocating (310) the data units to the subflows so that the data units having a particular said priority level are allocated to a said subflow having a corresponding said quality class.
5. A method according to claim 4, further including: arranging (308) the data units within a buffer in accordance with the assigned priority levels of the data units, and transferring the arranged data units from the buffer, in use, to the second device using the allocated subtiows.
6. A method according to preceding claim, further including applying a separate congestion control process (310) to each said subflow.
7. A method according to claim 6, wherein a said congestion control process (310) comprises a coupled MPTCP congestion control mechanism.
6. A method according to claim 3, wherein the step of analysing (306) the subtiows includes classifying the subflows into the quality classes, e.g. low and high, based on at least one data transfer quality-related factor of the subflows.
9. A method according to claim 3, wherein the step of analysing (306) the subtiows includes calculating a loss rate of a said subflow and assigning a said quality class to the subflow based on the calculated loss rate.
10. A method according to claim 9, wherein the calculating of the loss rate of a said subflow includes: transferring a number of data units using each said subflow; observing a number of lost data units within a time window for each said subflow, and calculating an average loss rate within the time window for each said subflow.
11. A method according to claim 10, wherein a said subflow that has a said calculated average loss rate less than a reference value is classified as a high said quality class subflow.
12. A method according to claim 3, wherein the step of analysing the subflows includes: calculating an expected delivery time to deliver a number of high said priority level said data units via a plurality of combinations of subgroups of the subflows, and classifying the subflows in a said subgroup with a lowest said expected delivery time as high said quality class.
13. A method according to claim 12, wherein the step of calculating the expected time includes: attempting delivery of the number of the data units through a said subgroup of the subflows, and performing recursive transmission of the number of the data units in order to calculate the expected time.
14. A method according to claim 3, wherein the step of analysing the subflows is performed dynamically in response to a condition of a network used for the MPTCP connection changing.
15. A method according to claim 1, wherein the step of extracting priority-related information includes processing cross layer information.
16. A method according to claim 15, wherein the cross layer information comprises information about data units crossing between session layer and transport layer.
17. A method according to any preceding claim, wherein the step of processing the priority-related information includes analysing (304) priority flagslsignals of the data units.
18. A method according to any one of claims ito 16, wherein the step of processing the priority-related data includes analysing (304) relevance order of the data units.
19. A method according to any preceding claim, wherein a said data unit comprises a SPDYTM message and the step of processing the priority-related data includes assigning a high said priority level to a said data unit comprising a said SF'DYTM message having a SYN_STREAM or SYN_REPLY high priority identifier.
20. A method according to any one of claims 1 to 18, wherein the data comprise video data wherein each said data unit is categorised as an I-frame, a P-frame or a B-frame, and the step of processing the priority-related data includes assigning a high said priority level to a said data unit comprising an I-frame and assigning a low said priority level to a said data unit comprising a said P-frame or a said B-frame.
21. A method according to claim 5, wherein the step of arranging (308) the data units in the buffer includes forward loading the data units having a high said priority level into the buffer and backward loading the data units having a low said priority level into the buffer.
22. A method according to claim 21, wherein the step of arranging (308) the data units in the buffer includes preventing loading of further said data units having a low said priority level into the buffer when remaining space in the buffer is only sufficient for loading of said data units having a high said priority level.
23. A system for transferring data between a first device (300) and a second device (302) over a Multipath Transmission Control Protocol (MPTCP) connection, the system including: a device configured to receive data to be transferred, in use, from the first device, the data comprising a set of data units; an analyser (304) configured to extract priority-related information for the data units from the received data; a processing device (306, 310) configured to process the priority-related information in order to allocate each said data unit to one of a plurality of subflows of the MPTCP connection, and a data transfer device configured to transfer (310) the data units, in use, to the second device over the MPTCP connection using the allocated subflows.
24. A system according to claim 23, wherein the analyser (304) is logically located within an AndroidTM framework and the processing device (306, 310) is logically located within a Linux kernel.
25. A system according to claim 23 or 24, wherein the MPTCP connection uses at least one wireless network.
26. A system according to claim 25, wherein the at least one wireless network comprises a 3G/LTE orWi-FiTM network.
27. A computer readable medium storing a computer program to operate a method according to any one of claims 1 to 22.
28. A method or a system substantially as described herein with reference to accompanying drawings.