BACKGROUND

Some embodiments described in the present disclosure relate to network communication and, more specifically, but not exclusively, to multiple data flows management.

With the advent and ubiquity of telecommunications networks and computing resources, more and more application programs and online services increase in complexity and data transfer volume and/or rate requirements, packing several flows of media optionally of different types, such as for example, visual, audio, tactile, control, telemetry, and/or any likewise media flows and/or flow types. Exemplary use cases include for example, holographic collaboration and conferencing applications, telemedicine, telesurgery and/or remote patient monitoring applications, remote industrial monitoring, machinery control and/or management applications, and/or the like.

Under pre-existing approaches and conventional standard transport protocols, even advanced ones supporting different streams, complex application programs and/or remote services simply open up several connections, one per each feed (i.e. data flow) utilized, whenever a different behavior from each of the feeds is required, such as for example, in terms of throughput, latency, maximum loss of packets, and/or any likewise performance requirements of a particular data flow transmitted and/or received by a network application at hand.

Such conventional approaches suffer from major drawbacks and disadvantages, due to introducing thereby a multiplicity of parallel signaling for connection establishment and requirements to maintain multiple security contexts (one per connection) consuming a lot of computing and storage resources, thus significantly burdening computer systems and communications networks and restricting scalability of such applications and/or services by result. SUMMARY

It is an object of the present disclosure to describe a system and a method for multiple data flow management.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to one aspect of the disclosed subject matter there is provided a method for multiple data flows management, comprising: receiving from a network application program a request for establishing a data transfer connection; obtaining service requirements of the data transfer connection comprising a number of a plurality of sub-flows and a plurality of Quality-of- Service profiles respective thereof for use by the network application program; transmitting to a server a request for establishing a multi-flow data connection according to the service requirements using a single network socket; responsive to receiving from the server an indication returned thereby that the server is configured for supporting the service requirements of the multi-flow data connection: determining, for a communication associated with the network application program, a sub-flow of the plurality of sub-flows to which the communication belongs; and, handling the communication in accordance with the sub-flow determined and a respective profile thereof of the plurality of Quality-of-Service profiles.

According to another aspect of the disclosed subject matter there is provided a computer program comprising program instructions which, when executed by a processor, cause the processor to perform a method for multiple data flows management, the method comprising: receiving from a network application program a request for establishing a data transfer connection; obtaining service requirements of the data transfer connection comprising a number of a plurality of sub-flows and a plurality of Quality-of-Service profiles respective thereof for use by the network application program; transmitting to a server a request for establishing a multi-flow data connection according to the service requirements using a single network socket; responsive to receiving from the server an indication returned thereby that the server is configured for supporting the service requirements of the multi-flow data connection: determining, for a communication associated with the network application program, a sub-flow of the plurality of sub-flows to which the communication belongs; and, handling the communication in accordance with the sub-flow determined and a respective profile thereof of the plurality of Quality-of-Service profiles. According to yet another aspect of the disclosed subject matter there is provided an apparatus for multiple data flows management, comprising a processing circuitry adapted to execute a code for: receiving from a network application program a request for establishing a data transfer connection; obtaining service requirements of the data transfer connection comprising a number of a plurality of sub-flows and a plurality of Quality-of-Service profiles respective thereof for use by the network application program; transmitting to a server a request for establishing a multi-flow data connection according to the service requirements using a single network socket; responsive to receiving from the server an indication returned thereby that the server is configured for supporting the service requirements of the multi-flow data connection: determining, for a communication associated with the network application program, a sub-flow of the plurality of sub-flows to which the communication belongs; and, handling the communication in accordance with the sub-flow determined and a respective profile thereof of the plurality of Quality-of-Service profiles.

Optionally the method further comprising monitoring network performance for the sub flow and reacting to degradation thereof beyond a predetermined threshold based on the respective profile.

Optionally the computer program further comprising program instruction to cause the processor to perform: monitoring network performance for the sub-flow and reacting to degradation thereof beyond a predetermined threshold based on the respective profile.

Optionally the processing circuitry is further adapted to execute code for: monitoring network performance for the sub-flow and reacting to degradation thereof beyond a predetermined threshold based on the respective profile.

Optionally determining the sub-flow comprises analyzing the communication, whereby the sub-flow is determined according to at least one of: a type of the network application program; one or more characteristics of the communication; and an indication provided by the network application program.

Optionally the communication is an outgoing communication for transmission to a remote device, and wherein handling the communication comprises assigning thereto a transport path compliant with the respective profile.

Optionally obtaining the service requirements comprises one of: the network application program providing an indication of the service requirements; and, retrieval of the service requirements from a pre-configured data store responsive to an identification of the network application program being indicated thereby. Optionally the service requirements comprise one or more of: a sub-flow identification; a sub-flow active/idle status; a sub-flow retransmission requirement; a sub-flow priority; a sub-flow maximum latency; a sub-flow minimum latency; a sub-flow minimum bandwidth; a sub-flow maximum bandwidth; and a sub-flow maximum loss.

Optionally the communication is provided with an added header comprising one or more of: a sender port; a receiver port; a sub-flow identification; a sub-flow sending count; a sub-flow acknowledgement; one or more transport flags; and an indication of at least one routing path.

Optionally a first communication sent by a participant entity during establishment of the multi-flow data connection comprises in an added header thereof an indication of an option of the multi-flow data connection being enabled, the indication comprising one or more of: a kind value; a length value; an identification of the network application program; a number of transmitted sub flows; and a number of expected sub-flows to be received.

Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which embodiments. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Some embodiments are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments may be practiced.

In the drawings: FIG. 1 is a schematic illustration of an exemplary network environment using a per flow connection for supporting different flow performance profiles of an application;

FIG. 2 is a schematic illustration of an exemplary network stack and control plane using a legacy transport protocol for supporting different flow performance profiles of an application;

FIG. 3 is a schematic illustration of an exemplary network stack and control plane using a sub-flow transport protocol for supporting different flow performance profiles of a non-aware application;

FIG. 4 is a schematic illustration of an exemplary network stack and control plane using a sub-flow transport protocol for supporting different flow performance profiles of a sub-flow aware application;

FIG. 5 is a sequence diagram of an optional flow of operations for establishment of a single connection supporting different flow performance profiles of an application;

FIG. 6 is a schematic illustration of an exemplary protocol data unit and sub-flow option header portion;

FIG. 7 is a schematic illustration of an exemplary network environment using a sub-flow transport connection architecture for supporting different flow performance profiles of an application;

FIG. 8 is a schematic illustration of an exemplary sub-flow transport layer architecture for supporting different flow performance profiles of an application; and

FIG. 9 is a schematic illustration of an exemplary architecture and optional flow of operations for sub-flow path computation.

DETAILED DESCRIPTION

Some embodiments described in the present disclosure relate to network communication and, more specifically, but not exclusively, to multiple data flows management.

An exemplary transport protocol currently in use is the Transmission Control Protocol (TCP) which is one of the main protocols of the Internet protocol suite. TCP accepts data from a data stream, breaks it up into transport segments and adds small amounts of metadata to each segment, including a sequence number used to detect lost or unorderly segments, and a checksum to allow detecting errors within segment data, upon either of which an automatic repeat request (ARQ) to the sender is issued. Another exemplary transport protocol being used is the Quick UDP Internet Connections (QUIC) protocol, which aims to be nearly equivalent to a TCP connection but with much reduced latency, it uses the User Datagram Protocol (UDP) rather than TCP as its basis, among other modifications for improving overall latency and throughput. Several key points and characteristics of the TCP and QUIC transport protocols which may be of relevance and/or interest in the context of some technical issues dealt with by the disclosed subject matter are summarized in the following Table 1. Advanced network applications such as for example, holographic conference calls, tele surgery, remote industrial monitoring and/or machinery control, and/or any likewise applications and/or services, may usually generate and consume several media streams (or flows) each with its own Quality of Service (QoS) requirements. For example, a holographic conference call may need several video feeds requiring high bandwidth and very low latency, audio flows requiring low bandwidth and bounded latency, a control flow with low bandwidth, and in case that a product is being presented it may require a tactile flow with low bandwidth and very low latency requirements.

Such numbers of flows per application may put an enlarged burden on end points and network resources (e.g., in terms of multiple states to be stored and managed for each flow) and impair the overall network capability to support large number of such applications, so scalability (one of the main requirements from large networks and a critical issue which can make-or-break an application’s success) is limited.

Under pre-existing approaches, in order to support multiple flows, a network application has to open a separate connection (usually TCP or QUIC) for each flow. Then each flow can be marked with a Differentiated Services Code Point (DSCP) tag that indicates the expected behavior of the network when handling the packets.

Such conventional approaches suffer from major drawbacks and disadvantages, as illustrated herein.

One issue with current approaches is that opening a separate connection for each flow means that for each one of the flows and respective opened connection thereof, a specific context is required to be generated and managed. If each application has several flows, then available resources are consumed fast.

Furthermore, another issue with current approaches is that for each such connection separately opened, an actual Quality of Service (QoS) level provided for a respective flow transported thereon, is in accordance with respective capabilities of routers and/or switches in a respective selected connection path. The guaranties that the network layer can provide are usually based on classes of services to which all flows requiring a specific quality of service are grouped together, without per-flow compliance to the required QoS verification. This lack of verification is observed both in the end points and in the network overall.

One technical challenge dealt with by the disclosed subject matter is to provide support for multiple data flows, as well as for explicit per flow performance requirements such as: throughput, latency, maximum loss, and/or the like, efficiently and in a scalable manner which cannot be accommodated by current approaches and/or conventional transport protocols used thereby.

In some embodiments, each flow may be considered as a sub-flow of a same connection, wherein for each distinct application, a single connection may be created which can carry several sub-flows, each being associated with a specific QoS profile (e.g., bandwidth, latency, loss rate and/or the like). For each sub-flow and required QoS profile thereof, a respective compliant routing path throughout the network may be sought for, and the sub-flows may accordingly be assigned to the respective complying paths found.

In some embodiments, continuous verification that the requested QoS level(s) for each sub flow are met by the respective assigned path may be performed. Optionally in case that a QoS level deteriorates beyond a configured threshold (optionally set to a value slightly higher than the actual QoS level required), a corresponding alert or notification may be issued. Additionally or alternatively, an alternate compliant path may be sought for and assigned to the sub-flow instead of the deteriorated path.

One technical effect of utilizing the disclosed subject matter is that an overall amount of computing and/or storage resources required to set and maintain a plurality of data flows transmitted and/or received by an application are reduced to a single connection, regardless of an overall number of such flows, thus improving efficiency, connection set-up time and scalability significantly, and optimizing transport layer resource allocation.

Another technical effect of utilizing the disclosed subject matter is that by requesting from the network respective compliant paths for different sub-flows used by an application, specific QoS requirements for each of the sub-flows can be guaranteed, and granular quality of experience can be provided.

Yet another technical effect of utilizing the disclosed subject matter is that by constantly monitoring the actual performance, and taking an action before the performance deteriorates, a seamless transition to a new path can be performed without impairing quality of user experience.

As used herein, the term “sub-flow” refers to one of multiple distinct data flows to be transmitted and/or received by an application program or service. Further, the terms “sub-flow”, “media flow”, “data flow”, and “feed”, may be used interchangeably throughout the present disclosure in a same meaning.

Throughout the present disclosure, the following terms and acronyms are used:

API - Application Programming Interface

DSCP - Differentiated Services Code Point

ID - Identification

IP - Internet Protocol

LSB - Least Significant Bit

MSB - Most Significant Bit

PCC - Path Computation Client

PCE - Path Computation Element

OSI - Open Systems Interconection

QoS - Quality of Service

QUIC - Quick UDP Internet Connections

RTT - Round Trip Time

SDU - Service Data Unit

TCP - Transmission Control Protocol UDP - User Datagram Protocol

Before explaining at least one embodiment in detail, it is to be understood that embodiments are not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. Implementations described herein are capable of other embodiments or of being practiced or carried out in various ways.

Embodiments may be a system, a method, and/or a computer program. The computer program may be provided online (e.g. via a telecommunications network). Or it may be provided as a computer program product. The computer program product may include a computer readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the embodiments.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of embodiments may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-seting data, or either source code or object code writen in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the later scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of embodiments.

Aspects of embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer programs according to embodiments. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer programs according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to FIG. 1 which is a schematic illustration of an exemplary network environment using a per flow connection for supporting different flow performance profiles of an application.

As shown in FIG. 1, a network application such as, for example, a holographic teleconferencing (HTC) application, may be deployed between at least two endpoints, such as Holographic Edge Unit 1 and Holographic Edge Unit 2. Without loss of generality, Holographic Edge Unit 1 and Holographic Edge Unit 2 may be a client and a server of the HTC application, respectively. Holographic Edge Unit 1 may comprise a Virtual Reality (VR) user equipment configured for receiving and reproducing a plurality of multimedia and/or data feeds. Holographic Edge Unit 2 may comprise a VR experience service system configured for generating and transmitting the plurality of feeds, optionally comprising a plurality of sensors for capturing a scene of interest, such as cameras, microphones, volume detectors, LiDAR scanners, and/or any likewise devices for acquiring images, sounds, and/or any other perceivable information and/or measurable data.

The plurality of feeds may comprise, for example, a visual feed requiring a high bandwidth and low latency (e.g., up to 10 milliseconds maximum), an audio feed requiring low bandwidth and low latency (e.g., up to 20 milliseconds maximum) for allowing synchronization with the visual feed, and a tactile feed requiring low bandwidth and ultra-low latency (e.g., up to 1 millisecond maximum).

Under current techniques using standard transport protocols such as TCP or QUIC, in order to support the different requirements, a separate connection should be opened and assigned to of each of the feeds, such as Connection 1 for the visual feed, Connection 2 for the audio feed, and Connection 3 for the tactile feed, respectively, as shown in FIG. 1. As result, parallel signaling upon connection setup is repeatedly performed multiple times, and similarly multiple allocations of connection resources (e.g., security contexts, packet buffers, and/or the like) are performed, thereby imposing a burden on both the network and the endpoints, in terms of traffic and/or computing resources.

Reference is now made to FIG. 2 which is a schematic illustration of an exemplary network stack and control plane using a legacy transport protocol for supporting different flow performance profiles of an application.

As shown in FIG. 2, under current techniques using TCP, QUIC and/or any likewise standard protocol(s), an application 100 in need of supporting different requirements of transmitted data flows may request a transport layer 105 to open a separate connection for each of the multiple flows, similarly as in illustrated in FIG. 1. The request may be conveyed to the transport layer 105 via an application programming interface (API) exposed thereby, denoted in FIG. 2 as App-Trans- API 180. Accordingly, the application layer 100 may configure a socket per each connection, denoted in FIG. 2 as SI, S2, ... , and/or SN. The transport layer 105 may forward to a network layer 110 packets for transmission via a corresponding API, denoted in FIG. 2 as Trans-Net- API 185. Once a connection is established, all packets of the respective flow may be transmitted by the transport layer 105 and network layer 110 through a same default path assigned for that connection, thus there are no guaranties that the service requirements for the flow are met in practice.

Reference is now made to FIG. 3 which is a schematic illustration of an exemplary network stack and control plane using a sub-flow transport protocol for supporting different flow performance profiles of a non-aware application. In some embodiments, a sub-flow transport layer 107 as shown in FIG. 3 may be employed in place of the transport layer 105 of FIG. 2. The sub-flow transport layer 107 may be configured to perform a similar functionality as of transport layer 105 of FIG. 2 and/or any other likewise standard transport layer (also known as Layer 4 in the OSI model) and may implement a sub-flow transport protocol such as disclosed herein.

As shown in FIG. 3, in some embodiments an application 100 may identify itself via an App-Trans-API 180 to the sub-flow transport layer 107, and may configure a single socket (denoted in FIG. 3 as SI) for the application 100. The sub-flow transport layer 107 may consult a pre-configured repository of applications profiles 120 each of which optionally being retrievable using a respective application identification, such as for example, a list, lookup table, database, and/or the like. Each of the applications profiles 120 may define a number of transmitted and/or received sub-flows and performance requirements thereof for a respective application identification. Optionally in case that the application identification is not found in the repository of applications profiles 120, the request may be either rejected or a normal TCP session may be initiated, per a configurable option of the sub-flow transport layer 107.

Using the respective one of the applications profiles 120 retrieved, the sub-flow transport layer 107 may request from the network layer 110 via the Trans-Net API 185 a path per sub-flow of the application 100 in accordance with the respective sub-flow requirements, optionally with guarantees that the performance requirements specified therefor are being met by the path assigned thereto by the network layer 110.

Reference is now made to FIG. 4 which is a schematic illustration of an exemplary network stack and control plane using a sub-flow transport protocol for supporting different flow performance profiles of a sub-flow aware application.

In some embodiments, the application 100 itself may provide to the sub-flow transport layer 107 an application profile defining a number of sub-flows required by the application 100 and performance requirements of each of the sub-flows, as shown in FIG. 4. The application layer 100 may configure a single socket for the application 100 and the sub-flow transport layer 107 may then request from the network layer 110 a per sub-flow path, optionally with guarantees, similarly as in FIG. 3.

Optionally, the application 100 may provide one or more general information items such as the following:

• Connection control: Open, Finish, Reset and/or the like • Connection parameters: Source IP, destination IP, source port MSBs, destination port

MSBs, and/or the like

• Application type

• Number of sub-flows

• Encryption required, where applicable

Optionally, the application 100 may further provide one or more per sub-flow QoS requirements and/or details such as the following:

• Sub-flow ID

• Sub-flow status: Active or Idle

• Retransmission required

• Priority

• Maximum latency

• Minimum latency

• Minimum bandwidth

• Maximum bandwidth

• Maximum Loss

Reference is now made to FIG. 5 which is a sequence diagram of an optional flow of operations for establishment of a single connection supporting different flow performance profiles of an application.

As shown in FIG. 5, a procedure for setting up a connection between two endpoints, such as for example, a client 500 and server 502, may generally comprise operations such as the following:

• Session initiating handshake

• Verification of capabilities such as: application support, hardware requirements, protocol compliance, etc.

• Start of the session

As an illustrative example, an exemplary connection setup based on the standard TCP connection procedure is described herein, however the disclosed subject matter is not limited in such manner and any other transport connection setup procedures may be employed in conjunction therewith, mutatis mutandis.

In some embodiments, the client 500 when initiating a sub-flow transport connection may at 510 send to the server 502 a SYN message with a sub-flow option embedded therein. The sub flow option in the SYN message may comprise an indication of capabilities required for the sub- flow transport connection, such as for example, an application identification, a number of sub flows to be transmitted and/or expected to be received by client 500, and/or any likewise information that may be specified in corresponding fields of the sub-flow option, as described herein.

Upon reception of the SYN message the server 502 may at 514 verify that:

• Sub-flow transport protocol is supported by the server 502

• The application identification indicated by an “Application ID” field is supported by the server 502

• The number of sub-flows indicated in the “Transmit sub-flows” field can be accepted by the server 502

• No more sub-flows than the amount indicated in the “Expected sub-flows” field may be transmitted by the server 502

In case that any of the above tests fails, then the server 502 may ignore the sub-flow option and continue as if the connection is standard TCP, and accordingly may not append the sub-flow option in a SYN+ACK message sent at 518 by the server 502 in response to the SYN message of the client 500.

If all tests succeed, the server 502 may at 518 send a SYN+ACK response message comprising the sub-flow option. The sub-flow option fields in the response may be equal to the ones in the received SYN message, except that:

• In the “Transmit sub-flows” field the server 502 may indicate the actual number of sub flows that it will transmit, which may not exceed the number indicated by the client 500 in the “Expected sub-flows” field

• In the “Expected sub-flows” field the server 502 may specify the same value received from the client 500 in the “Transmit sub-flows” field

Upon reception of the SYN+ACK message from the server 502, the client at 522 may verify that the sub-flow option is embedded therein. If not, then the client 500 may either tear down the connection (e.g., send a RST message for immediate reset of the connection) or, if applicable, continue with a normal TCP connection.

If the sub-flow option is embedded in the SYN+ACK message, then the client 500 may at 522 verify consistency with the transmitted sub-flow option, and if the respective fields match, the client 500 may at 526 send an ACK message to the server 502 and at 530 start the data transfer phase. In case of a simultaneous sub-flow transport connection openning (e.g., SYN message received by the client 500 after sending a SYN message), the sub-flow option may be embedded in a SYN+ACK message sent in response to the SYN message recieved by the client 500 in the same way as described for the normal case.

Sub-flow transport connection tear down may be equal to TCP tear down. Either side may terminate the session, regardless of which one was the initiator. The session termination may comprise operations such as the following:

• Send finish indication (FIN message)

• Receive finish confirmation (FIN+ACK message)

• Release resources

Reference is now made to FIG. 6 which is a schematic illustration of an exemplary protocol data unit and sub-flow option header portion.

A protocol data unit 600 may be, for example, an IP packet, as shown in FIG. 6. The protocol data unit 600 may comprise an IP header 610, a TCP fixed header 620, an options 630 variable portion of the TCP header, a payload 640, and/or the like. The options 630 portion of the TCP header may copmrise a sub-flow option 635 such as shown in FIG. 6 and described herein.

In some embodiments, the TCP fixed header 620 may comprise fields with functionalities such as the following:

• Source port: 10 MSBs (bits 6:15) may indicate a TCP connection port at a source, 3 LSBs (bits 3:5) may be reserved for future sub-flows scalability and 3 LSBs (0:2) may indicate a sub-flow which data therof being carried in the segment payload 640. For connection control (connection set-up, tear-down, reset) 3 LSBs may be set to zero.

• Destination port: 10 MSBs (bits 6:15) may indicate a TCP connection port at a destination, 3 LSBs (bits 3:5) may be reserved for future sub-flows scalability and 3 (0:2) LSBs may indicate a sub-flow which data therof being acknowledged. For connection control (connection set-up, tear-down, reset) 3 LSBs may be set to zero.

• Sequence number: If a SYN flag is set (1), then a value specified may be an initial sequence number for all sub-flows. If a SYN flag is clear (0), then the value may be an accumulated sequence number of a first data byte of the segment for a sub-flow identified by the 3 LSBs of the source port number.

• Acknowledgement number: If an ACK flag is set then a value specified may be a next sequence number that a sender of the ACK is expecting for a sub-flow identified by the 3 LSBs of the destination port. The ACK flag may acknowledge receipt of all prior bytes (if any) for the sub-flow.

• Data offset: Specifies a size of the TCP header in 32-bit words. In case of sub-flow transport connection, the sub-flow option 635 may be specified in a first message sent by each side during a handshake.

• Flags: Same as for TCP.

• Window size: A size of a receive window, which may specify a number of window size units that a sender of the segment may be currently willing to receive for a sub-flow indicated by the 3 LSBs of the destination port.

• Checksum: Same as for TCP.

• Urgent pointer: Not used.

• Options: A first message sent by each side during handshake (SYN flag set) may include at least the sub-flow option 635.

As shown in FIG. 6, the sub-flow option 635 may be specified in the options 630 portion of the TCP header of the segment, and comprise fields and functionalities such as the following:

• Kind: sub-flow option. An exemplary value therefor may be 253.

• Length: A total size in bytes of the option, for example 6 bytes as shown in FIG. 6.

• Application ID: An application identification number of an application using the connection.

• Transmitted sub-flows: Number of sub-flows to be transmitted by the sending end of the connection. An exemaplary value range may be 0-7.

• Expected sub-flows: Number of sub-flows expected to be to received by the sending end of the connection from its peer. An exemaplary value range may be 0-7.

Reference is now made to FIG. 7 which is a schematic illustration of an exemplary network environment using a sub-flow transport connection architecture for supporting different flow performance profiles of an application.

As shown in FIG. 7, a network application such as the HTC application of FIG. 1, may require transmission from one endpoint to another, such as an HTC server and client, respectively, of a plurality of data flows with different performance requirements for each, such as for example, a visual, audio, and/or tactile feed(s). A single connection between the two endpoints supporting a plurality of sub-flows, where the different feeds of visual, audio, and/or tactile data may each be assigned a distinct sub-flow within the connection, may in turn substitute the multiple connections usage of FIG. 1. Reference is now made to FIG. 8 which is a schematic illustration of an exemplary sub flow transport layer architecture for supporting different flow performance profiles of an application.

Reference is also made to FIG. 9 which is a schematic illustration of an exemplary architecture and optional flow of operations for sub-flow path computation.

Referring now to FIG. 8, the sub-flow transport layer components and functionality thereof are described hereinafter.

App-Trans API

In some embodiments, in the transmit direction, an application (such as 100 of FIGS. 2 - 4) may send to a sub-flow transport layer (such as 107 of FIGS. 3 - 4) via an App-Trans API 180 full data segments referred to herein as Service Data Units (SDUs), each SDU containing data from a single sub-flow. The sub-flow may be identified by the application, in which case the operation of the sub-flow transport layer may be simplified, but if the application is not able or ready to identify sub-flows, such as may be the case in a setting as the one illustrated herein in FIG. 3 or similar thereto, the sub-flow transport layer may identify the respective sub-flow based on the SDU characteristics.

In some embodiments, in the receive direction, the sub-flow transport layer may forward the received SDUs to the application. The sub-flow transport layer may also monitor the sub-flow performance. In case that the requested QoS cannot be met for a specific sub-flow, the sub-flow transport layer may send an indication to the application and/or to a Path Computation Client (PCC) such as 910 of FIG. 9.

TRANSMIT PIPELINE

The transmit pipeline blocks may be responsible for forwarding the data received from the application layer through the App-Trans API 180, as sub-flow transport protocol segments to the network layer through the Trans-Net API 185.

Classifier

A classifier 804 may receive the SDUs from the App-Trans API 180 and identify the sub flow corresponding thereto. In case the application provides the sub-flow identification, the classifier 804 may use this information. In case that the application does not provide such identification, the classifier 804 may analyze the SDU header to identify the sub-flow according to the application type. Tagging

Once the SDU sub-flow is identified by the classifier 804, a sub-flow identification tag may be added by a tagging module 808 to allow quick and easy sub-flow identification by subsequent components of the transmit pipeline. The tag may be carried in a respective sub-flow transport protocol header and/or otherwise within the segment, such as for example in the LSBs of the source port similarly as described herein with reference to FIG. 6, as a special sub-flow identification tag carried in a transport layer option, as part of the segment payload, and/or the like.

Encryption

Once identified and tagged, the SDU may be encrypted by an encryption module 812, since all the required information to transport the packet is embedded in the tag added by the tagging module 808. The encryption function of 812 may be optional and not an integral part of the sub flow transport protocol disclosed herein, but as a person skilled in the art will readily appreciate, in case that it is implemented, notably there may be a single instance of encryption control channel for all the sub-flows (no per sub-flow encryption control channel).

Transmit buffers

Each sub-flow may be assigned to one of transmit buffers 816 which operation thereof may be controlled by a congestion control function such as 852 (note that the congestion control function may be implemented using known techniques and which are not part of the sub-flow transport protocol disclosed herein). Packets may be written into the respective one of the transmit buffers 816 as received from the tagging of 808 or the encryption function of 812 (if implemented) and transmitted according to commands of a scheduler 820.

In case that no-retransmission may be required by the application for a sepcific sub-flow, the packet may be removed from the buffer once transmitted, but the congestion control 852, and similarly a performance monitoring function such as 856, may still expect to get a respective acknowledgment indication to detect packet loss.

Scheduler

A scheduler 820 may extract the packets from the transmit buffers 816 according to commands it may receive from the congestion control 852 function.

Path Selector

A path selector module 824 may get input from several modules:

• Per sub-flow QoS requirements, such as indicated by the application and/or determined by the classifier 804 according to the application type specified in the SDU header. • Application’s available paths and ports, which may be obtained from a path computation element (PCE) such as 915 of FIG. 9, as described in further detail herein.

Based on the inputs received, the path selector 824 may detect a path (or a plurality of paths) that complies with the sub-flows QoS requirements, and may then assign the sub-fllows accordingly. In case that a sub-flow can not be served by the available paths, the path selector 824 may send an indication to the application and to the PCC 910.

Add header

Before forwarding the packet to the network layer, a sub-flow transport layer header may be added by a respective function such as one of sub-flow add headers 828 to create a transport layer segment. The header may include one or more information items such as the following:

• Sender port

• Receiver port

• Send sub-flow identification tag (added by the tagging function such as 808)

• Sub-flow sending count (e.g., a sequence number)

• Sub-flow acknowledgment

• Flags

In some embodiments, the sender and receiver ports may identify a connection (MSBs of the port number) and respective sub-flows thereof (LSB of the port number). The connection set up may use one source and destination port (sub-flow “0”). Segments may be transmitted only after the requested paths have been provided by the PCE 917, and each sub-flow been assigned to the relevant QoS requirements compliant path. The standard TCP flags may be used to initialize and close the connection. The segment payload and header thereof may be formatted in a manner such as described herein and shown with reference to FIG. 6.

Trans-Net API

The full formatted segments may be forwarded to the network layer through the Trans-Net API 185. The network layer may add its header and extension headers (or options), however as a person skilled in the art may readily appreciate, notably the way this may be done by the network layer may entail known techniques not being part of the disclosed subject matter.

Received segments may be forwarded to the sub-flow transport layer.

RECEIVE PIPELINE

The receive pipeline blocks may be responsible for forwarding the data received from the network layer trough the Trans-Net API 185, to the application layer through the App-Trans API 180. Header monitor

A header of a received segment may be analyzed by a header monitor 832 to identify the segment sub-flow and to detect acknowledgments specified therein, optionally using an ACK flag selectively, similarly as described herein with reference to FIG. 6. The received segments may be forwarded to corresponding sub-flow receiver buffers 836, while the acknowledgment information may be forwarded to the connection control 848 function for connection maintenance, to the congestion control 852 function to measure a respective RTT and detect segment losses, and to the performance monitoring 856 function to verify QoS parameters compliance.

The header monitor may remove the transport header from the segment.

Receive buffers

To avoid head of the line blocking, each sub-flow may be assigned to a different one of the sub-flow receive buffers 836. Segments may be written by the header monitor 832 function as received, and read out by the decryption 840 function if implemented or directly by the application through the App-Tran API 180 after removal of a sub-flow identification tag by a remove tag 844 function.

Decryption

Decryption may not be part of the sub-flow transport layer, but if encryption is used then the decryption 840 function may decrypt the segment and generate the SDUs for the application.

Remove Tag

A remove tag 844 function may remove from the recieved and optionally decrypted segment a sub-flow identification tag as added thereto at a sender end prior to transmission by the tagging 808 function.

TRANSMIT AND RECEIVE PIPELINE FUNCTIONS

The transmit and receive pipelines blocks and overall operation thereof may be controlled by the sub-flow transport layer protocol functions. Modules in the transmit pipeline or a portion thereof performing control and/or monitoring function(s) may use and/or rely on network feedback for optimizing network resource utilization. Such feedback may be monitored by the header monitor 832, within the receive pipeline.

Each of the modules for network resource management are discussed herein in further detail.

Connection control

Connenction control 848 may perform a functionality similar to standard TCP connection control (for TCP protocol details see for example: https://tools.ietf.org/html/rfc793). The connection control 848 function may try to set up a transport layer session with a remote end, as indicated by a destination IP. The connection control 848 function may also receive a request from a remote end to set up a session, in which case it may verify that there is a compliant application for the requested session.

The session setup may be carried out similarly as shown in FIG. 5 and described herein with reference thereto.

Performance monitoring

Each sub-flow performance is monitored to verify compliance with the requested QoS parameters. The performance monitoring function receives the requested parameters from the application for each QoS parameter and sets a configurable guard threshold slightly better than the requirement for all sub-flows. If the guard threshold is crossed the performance monitoring function sends a warning to the application and may in parallel try to find a better path for the sub flow. If any of the QoS parameters cannot be met, the performance monitoring function indicates this situation to the application. The application is responsible to decide if the service can still be maintained, or if it will be shut down.

Congestion control

Congestion control is not part of the invention. Any congestion control method that can be instantiated for several sub-flows can be used.

SUB-FLOW NETWORK HANDLING

Referring now to FIG. 9, providing to each sub-flow of an application 100 a requested QoS may be achieved by finding a network path that has high probability of supporting the requested QoS.

In some embodiments, a sub-flow transport layer 107 may forward to the Path Computation Client (PCC) 910 the sub-flow parameters, and the PCC 910 may use a PCE-P protocol to approach a Path Computation Element (PCE) 915 and request such paths for the respective sub-flows. If no such path may be available, the PCE 915 may indicate that the request failed. Such indication may be forwarded to the application 100 by the sub-flow transport layer 107 and the application 100 may decide if the service cannot be provided, or try to loosen the QoS requirements.

Once a compliant path has been detected, the PCE 915 may respond with a tag or source routing extension to be attached to the sub-flow packets to guarantee that these packets flow through the computed path. The sub-flow identification tag may be part of the network header. Regardless of the capabilities available at the network and link layers, the sub-flow transport layer 107 may optimize resource utilization while providing the best performance for each sub-flow. If the network and link layers are able to find diverse paths for the sub-flows according to their QoS requirements, the sub-flow transport layer 107 may take advantage of these paths by assigning the sub-flows to the path that complies with their QoS requirements. If the network and/or link layers are not able to provide diverse paths, or are able to provide only a limited number of such paths, the sub-flow transport layer may group the sub-flows to the provided paths according to their QoS requirements.

If the performance monitoring 856 function of the sub-flow transport layer 107 detects that any path QoS parameter performance has degraded beyond the guard threshold the sub-flow transport layer 107 may send an indication to the application 100. In addition, the sub-flow transport layer 107 may approach in parallel the PCC 910 to request a new path from PCE 915.

The way the PCE 915 may leam the network and/or link capabilities and compute the paths may be by using known techniques beyond the scope of the disclosed subject matter. As a person skilled in the art may readily appreciate, notably the number of sub-flows in each direction is not required to be the same.

It will be appreciated by a person skilled in the art that by identifying the different sub flows of the network application the disclosed sub-flow transport layer can signalize their requirements accurately. It will further be appreciated by a person skilled in the art that the disclosed sub-flow transport protocol can easily be upgraded to negotiate the basic application networking requirements during the set-up phase.

The descriptions of the various embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. It is expected that during the life of a patent maturing from this application many relevant sub-flows management techniques will be developed and the scope of the term sub-flows management is intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %. The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of.

The phrase "consisting essentially of means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of embodiments. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of embodiments, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of embodiments, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements. Although embodiments have been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

It is the intent of the applicant(s) that all publications, patents and patent applications referred to in this specification are to be incorporated in their entirety by reference into the specification, as if each individual publication, patent or patent application was specifically and individually noted when referenced that it is to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.