Patent Description:
Implementation of multipath protocols such as MPTCP potentially improves the way current computer networks operate by using the resource pooling principle to improve the reliability and throughput of a data communication session. For example, if a communication path between a source and a destination breaks down, or becomes highly congested, data may be sent over alternative paths to thereby avoid any interruption in the data communication session.

Moreover, a multipath protocol potentially enables a client, e.g. a mobile device, to simultaneously establish a connection through multiple network interfaces. Modern communication devices (e.g., smart phones and other handheld communicators, tablet computers with communication functionality, etc.) often possess multiple network interfaces for use with different network technologies having different connectivity characteristics. Such interfaces can provide connections to a cellular network, wired and wireless Local Area Network (LAN), or other devices in an ad-hoc or peer-to-peer mode. The different network technologies may each have, for example, different delay, throughput, and reliability characteristics. For example, a mobile device that is connected to a remote source node through both a cellular network and an IEEE <NUM> wireless LAN may observe different usage costs and quality of service through the respective interfaces.

A goal of multipath protocols such as MPTCP may be to utilize multiple available paths and network resources to carry out communications, to increase throughput, decrease data transit time, and/or make efficient use of available resources. The desire for such benefits has increased with the emergence of more capable (in terms of computational power and communication interfaces) devices. Existing multipath proposals and implementations are limited in one or more respects. For example, one problem in MPTCP is scheduling. The problem of scheduling in MPTCP involves partitioning the data across multiple paths, and dynamically re-adjusting the schedule based upon congestion feedback.

The use of coding in general, specifically Random Linear Network Coding (RLNC), has been proposed to alleviate the scheduling problem of multipath communication. <CIT> ("'<NUM> patent") describes techniques to facilitate multi-path transmission by implementing a transport protocol that emulates current Transfer Control Protocol (TCP)/MPTCP interface (to higher and lower layers) and provides a more effective service using coding. <CIT> ("'<NUM> patent") describes, in certain embodiments, using RLNC in a manner that takes advantage of conventional communication techniques and protocols, providing robustness to link failures particularly in wireless networks as well as the ability to roam from one network to another. For example, the '<NUM> patent describes embodiments that can operate over conventional transport layer protocol (e.g., TCP).

As is also known in the art, there exist transport-layer protocols that are designed to operate over UDP (User Datagram Protocol). One such protocol is QUIC, which was primarily designed to reduce latency through (<NUM>) the removal of head-of-line blocking seen by Transmission Control Protocol (TCP) by establishing a set of multiplexed connections between the endpoints, (<NUM>) an improved estimation of congestion, and (<NUM>) the inclusion of a form of forward error correction (FEC). The word "QUIC" is sometimes used as an acronym for "Quick UDP Internet Connections," however the IETF uses "QUIC" as a protocol name, not an acronym.

The extension of QUIC to multipath operation has been proposed. See, for example, <NPL> (hereinafter "De Coninck"). A subsequent informational Internet Draft summarizes a set of suggested multipath requirements for QUIC, see <NPL> (hereinafter "Huitema"). De Coninck proposes a congestion control mechanism that is managed individually at the path level, where a handshake is provisioned for establishing multipath connection. As suggested in Huitema, De Coninck allows path-independent acknowledgements (i.e., feedback) to be transmitted between the endhosts (i.e., the source and the destination nodes). De Coninck proposes additional protocol features, such as path update frames, path state management, and an acknowledgement format, and provides for the collection of path statistics by the endhosts for flow control purposes. <NPL> discloses MDMA, a distributed MU-MIMO MAC protocol that achieves both multiplexing and receive diversity gains at the same time. Instead of letting a node pair use its full degrees of freedom, MDMA allows as many contending node pairs as possible to transmit concurrently and share all the available degrees of freedom. By doing this, MDMA exploits more antennas equipped at different receiving nodes to provide concurrent streams more receive diversity, without sacrificing the multiplexing gain.

According to one aspect of the present disclosure, there is provided a machine-implemented method for use at a destination node for transferring data from a source node according to claim <NUM>.

According to another aspect of the present disclosure, there is provided a machine-implemented method for use at a source node for transferring data to a destination node according to claim <NUM>.

According to another aspect of the present disclosure, there is provided a device for use at a destination node for transferring data from a source node according to claim <NUM>.

According to another aspect of the present disclosure, there is provided a device for use at a source node for transferring data to a destination node according to claim <NUM>.

The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more embodiments of the present disclosure and, together with the description of example embodiments, serve to explain the principles and implementations of the disclosure.

The present disclosure relates to methods and devices to enhance multipath communications using coding. Embodiments of the present disclosure can achieve coded multipath transport through a multi-window design where the source and destination nodes maintain a destination-driven sliding sub-window associated with each path. In some embodiments, a multi-window pull mechanism can be used in protocols that are the same as or similar to the QUIC transport-layer protocol. While the multi-window design disclosed here may use the QUIC protocol as a template, the techniques described herein may be applied to other transport protocols.

<FIG> illustrates multipath QUIC communication in a computer network <NUM>, as known in the prior art. A source (or "sender") <NUM> is communicatively coupled to a destination (or "receiver") <NUM> via a plurality of paths 150a, 150b, etc. (<NUM> generally). A path <NUM> corresponds to a logical association between the source <NUM> and the destination <NUM>. Multiple paths <NUM> exist between the source and the destination. For example, paths from a video server to a smartphone can be established via different radio interfaces such as WiFi and LTE. The example of <FIG> includes two paths 150a, 150b.

The source <NUM> and destination <NUM> may correspond to the endhosts (or "hosts") of a transport operation, performing multiplexing and encapsulation operations required at the transport layer. As shown in <FIG>, multiplexing is performed by way of a multiplexer <NUM> at the source <NUM> and a demultiplexer <NUM> at the destination <NUM>. The source <NUM> and destination <NUM> may also perform flow control and reliability operations.

Multiple data streams 120a, 120b, etc. (<NUM> generally) are established between the source <NUM> and the destination <NUM>. A data stream (or "stream") <NUM> is used to transmit application data from the source <NUM> to the destination <NUM>. In the example of <FIG>, source <NUM> is shown sending two data streams 120a, 120b to the destination <NUM>. Each stream <NUM> is segmented or mapped into one or more frames (e.g., frame <NUM>). Frames from different streams <NUM> are multiplexed together and formed into packets (e.g. packet <NUM>) and transmitted across one or more of the paths <NUM>. Frames and packets can also carry control information.

One or more connections 140a, 140b, 140c, 140d, etc. (<NUM> generally) are established between the source <NUM> and the destination <NUM>, with each connection associated with a given path <NUM>. A connection <NUM> carries packets between the source <NUM> and the destination <NUM> and may be characterized by different properties such as error rate, delay, encryption requirements, reliability, etc. In the example of <FIG>, a first path 150a has one connection 140a whereas a second path 150b has three connections 140b, 140c, 140d.

Data flow in transport protocols typically starts with a request from the destination <NUM>, usually in the form of a number of octets (or bytes). Such requests typically follow a credit-based flow control protocol, examples of which include QUIC and Hypertext Transfer Protocol <NUM> (HTTPS/<NUM>). In such protocols, credits represent permissions to transmit a given number of octets.

Transport protocols such as TCP and QUIC typically rely on a sliding-window at both the source <NUM> and destination <NUM> to track sent and received frames (or packets). At the source <NUM>, feedback from the destination <NUM> in the form of packet acknowledgements (ACKs), coupled with transmission credits, enable the source <NUM> to remove frames from its window, thus allowing it to insert new frames from the stream, slide the window, and carry on with the transmission. The destination <NUM> inserts received frames into its window and typically removes them when they are transmitted in order to a stream-requesting application.

Turning to <FIG>, coded transport protocols such as the ones described in the '<NUM> and '<NUM> patents carry out the coding of data units (e.g., frames or packets) to enable multipath operation and improve reliability. Such coded protocols are able to introduce redundant erasure-correcting data units (redundancy) at any node in the network (e.g., at a data "chokepoint") and, as such, can be used to achieve a desired coding rate for a stream or connection.

Coded transport protocols use the notion of coded degrees of freedom (DoFs), where DoFs are transport data units that are useful for the decoding operation. In this disclosure, the term degree of freedom (DoF) is used to denote a coded or uncoded (i.e., native) data unit. In RLNC, a coded data unit is a linear combination of uncoded data units. A DoF window, or coding window, is utilized by a source to control the amount of data it codes together at any given time, and at a destination to collect received packets and carry out decoding operations, such as described in the '<NUM> and '<NUM> patents.

A DoF window is defined by the DoFs (i.e., coded and uncoded frames) contained within the window, where each uncoded frame may be viewed as a linear combination involving data units within a single frame. Since each frame can be represented by a coefficient array, a DoF window can be represented by a matrix of coefficients of its constituent frames, with the rows representing sent or received DoFs and the columns representing uncoded frames (see, e.g., the '<NUM> and '<NUM> patents).

The transmission of DoFs, such as described in the '<NUM> and '<NUM> patents, can be carried out through a push mechanism, where the size of the source's DoF window is determined by the source. The present disclosure exploits destination requests temporally to generate a decodable transmission through a pull mechanism.

In such requests, the destination announces to the source one or more coding-related parameters. The destination can send a request to the source specifying a number of coded degrees of freedom (DoFs) and/or the number of frames that the destination is willing to receive per stream, per path, and per connection. The destination sends an updated request to the source as packets are received and decoded, as long as the transmission is not terminated. Transmission paths are updated based on receiver requirements and observed connection statistics.

Using the techniques disclosed herein, a destination can ensure decodability through its requests to the source. In some embodiments, decodable transmissions may be self-contained so that decoding can occur in a relatively short period of time (in contrast with a conventional "globally decodable" approaches where decodability is not required from each transmission).

A destination's request for data can include information about the amount of coded data it is willing to receive, and additional parameters described below. A destination can request maximum degree of freedom (DoF) windows to the source, where a maximum DoF window is a number of frames (or other units of data) it is willing to receive. In addition to the DoF window specific to each stream, each connection may have a unique DoF window (referred to as a sub-window), resulting in multiple DoF windows per data transmission session. The destination's request may also include the overall amount of data (e.g., number of frames or octets) it can receive (e.g., as specified by QUIC), as well as potential Quality of Service (QoS) requirements. Such QoS requirements may include temporal restrictions for decoding (e.g., decoding deadlines). The maximum DoF window may also capture the total amount of data (e.g., number of frames or octets) that the destination can process, hence reflecting the decoding capabilities of the destination. The destination may increase the DoF window per stream, per connection and/or per path in order to allow for more data to be transmitted.

The methods described herein include the use of path-agnostic and path-specific DoF ACKs and a destination-side credit-based sliding DoF window. In this disclosure, the destination monitors transmission statistics and requests the source to adjust its coding window and scheme accordingly (e.g., modification of the code rate). This adjustment can be made for transmissions over a single path, or across multiple paths between the source and destination.

The destination acknowledges (ACKs) received DoFs. This acknowledgment can be sent per connection (connection-specific), or at the stream level. Stream-level ACKs are path-agnostic and can be sent via return frames over any path established between the source and the destination. Frames produced by a single stream may therefore be encoded with different levels of redundancy depending on the connection they use.

In addition to the DoF window, the destination may request redundancy requirements based on connection statistics (e.g., packet or frame loss rates) and the coding rate to be used by the sender. The coding rate may be determined by resource constraints available at the receiver (e.g., memory availability, processor power, battery) and QoS requirements (e.g., delay, time to decode, jitter). The destination request may also specify the redundancy or the coding rate.

The destination uses information available locally in order to determine connection statistics and build its requests to the source. Such information may include monitoring of device resources (e.g., memory, processing capabilities), channel state information, path state information, congestion information, and user input constraints (e.g., pause in application usage). Such information may further include congestion level, packet/frame loss, packet/frame delay, throughput, application/network QoS requirements (e.g., time to decode, packet/frame delay/jitter), node memory size (e.g., coding/decoding buffer size, receiver buffer size), processor power (e.g., coding/decoding speed), or any stream-, path, or connection-level performance metrics computed or collected by the destination. A destination may establish or terminate connections over existing or new paths, terminate existing paths, and adjust the DoF window size and sender coding scheme (e.g., code rate) based on such information.

The destination coordinates with the source two levels of redundancy: a connection-level redundancy, determined per connection and managed by the connection-level DoF window, and a stream-level of redundancy across multiple connections via multiplexing of encoded stream frames and managed by a stream-level DoF window.

The methods described herein are compatible with flow-control algorithms that govern the amount of data (e.g., number of frames or octets) the source is allowed to transmit at any time across any given stream and/or connection. The focus is rather on a coding-based approach to multipath operation and reliability.

<FIG> illustrates coded multipath network communication using multi-window operation, according to an embodiment of the current disclosure. An illustrative computer network <NUM> includes a source <NUM> and a destination <NUM> which can be communicatively coupled by a plurality of paths 250a, 250b, etc. (<NUM> generally), according to an embodiment of the present disclosure. The example of <FIG>, the network <NUM> includes two paths 250a, 250b, however it will be understood that the techniques disclosed herein can be used with more than two paths. The paths <NUM> may include wireless paths (e.g., paths over WiFi and LTE), wired paths (e.g., Ethernet paths), and/or a combination of wireless and wired paths.

The source <NUM> may include an encoder-multiplexer <NUM> configured to perform encoding and multiplexing operations as discussed herein. The destination <NUM> may include a demultiplexer-decoder <NUM> configured to perform corresponding demultiplexing and decoding operations.

One or more data streams 220a, 220b, etc. (<NUM> generally) are established between the source <NUM> and the destination <NUM>. A stream <NUM> corresponds to a logical connection between the source <NUM> and the destination <NUM> across which data is transmitted for an application. A stream <NUM> is segmented or mapped into one or more frames (e.g., frame <NUM>). While two streams 220a, 220b are shown in <FIG>, the techniques and structures disclosed herein can be applied to an arbitrary number of streams.

One or more connections 240a, 240b, etc. (<NUM> generally) are established between the source <NUM> and the destination <NUM>, with each connection associated with a given path <NUM>. A connection <NUM> carries packets between the source <NUM> and the destination <NUM> and may be characterized by different properties such as error rate, delay, encryption requirements, reliability, etc. In the example of <FIG>, a first connection 240a is established over path 250a and a second connection 240b is established over path 250b. In some embodiments, multiple connections <NUM> may be established over a single path <NUM>.

Frames from the one or more streams <NUM> can be encoded and multiplexed onto the one or more connections <NUM> by encoder-multiplexer <NUM>. For each stream 220a, 220b, the source <NUM> maintains a corresponding "stream-level" DoF window 221a, 221b (<NUM> generally). The source encodes frames present in the stream-level DoF window <NUM> to generate redundant coded frames (e.g., frame <NUM>). In <FIG>, coded frames are shown using hatching, whereas uncoded frames are shown in solid fill. Coding is performed on the frames of each stream <NUM> using, for example, network coding, with coding coefficients generated either randomly or using a structured code.

The source <NUM> may inject the redundant coded frames (e.g., frame <NUM>) into the multiplexed stream of uncoded frames, and the coded and uncoded frames may be formed into packets (e.g., packet <NUM>). For each connection 240a, 240b, the source maintains a respective "connection-level" DoF window 241a, 241b (<NUM> generally). The connection-level DoF windows <NUM> may be referred to as subwindows, since they contain representations of data that are already in the stream-level DoF window <NUM>.

The destination <NUM> also maintains connection-level DoF windows 261a, 261b (<NUM> generally), which mirror the source's connection-level DoF windows 241a, 242b. The connection-level DoF windows <NUM> at the destination allow the destination to monitor the arrival of DoFs over each connection <NUM>. The destination <NUM>-or more particularly, demultiplexer-decoder <NUM>-can demultiplex and decode data received over each of the connections <NUM> to generate received streams 280a, 280b (<NUM> generally). Received streams 280a, 280b may correspond to source streams 220a, 220b, respectively.

For each received stream 280a, 280b, the destination <NUM> maintains a corresponding stream-level DoF window 281a, 281b. The destination <NUM> uses the stream-level DoF windows <NUM> to monitor DoFs in the received streams <NUM> and to carry out stream decoding. In some embodiments, stream-level DoF windows <NUM> may be maintained by the demultiplexer-decoder <NUM>.

In <FIG>, dashed arrow <NUM> shows the direction of flow of DoFs from the source <NUM> to the destination <NUM>. Each DoF can correspond to a stream and connection identifiers. Dashed arrow <NUM> shows the direction of flow of control information from the destination <NUM> to the source <NUM>. Control information includes, for example, DoF acknowledgements (ACKs) and maximum DoF window size updates.

In some embodiments, control-plane signaling may be used between the source <NUM> and destination <NUM>. The destination <NUM> sends control frames or packets to the source <NUM> to perform stream initialization (e.g., initial data requests), DoF ACKs, and maximum DoF window size requests. A destination may "update" or "announce" new maximum DoF window sizes to the sender as part of a data request. A maximum DoF window size request can identify a specific stream <NUM>, path <NUM>, or connection <NUM>.

For example, upon detecting an increase in the losses over second path 250b, the destination <NUM> may increase the source's DoF windows for all connections carried by the second path 250b. Thus, in the example of <FIG>, destination <NUM> may send a request to increase the maximum size of DoF window 241b, but not of DoF window 214a. The destination may also request an increase in the maximum size of the stream-level DoF window <NUM>. By requesting an increase in the maximum DoF window sizes, destination <NUM> can induce the source <NUM> to send more DoFs over the second path 250b to compensate for the added losses. In some embodiments, the destination <NUM> may take into account flow control credits available for each path <NUM> and/or each connection <NUM> in order to determine an appropriate size for the connection-level DoF windows <NUM> and/or for the stream-level DoF window <NUM>.

The amount of redundancy in each stream and connection can be implicitly dictated by the destination <NUM> through the maximum DoF window size requests. However, redundancy levels may also be set through the addition of explicit stream-level or connection-level code rate fields to the control frames (e.g., ACKs or updates) that are sent from the destination to the source.

In some embodiments, a second coding stage may be implemented at the source connection endpoints (e.g., 240a, 240b) to create connection-specific redundancy, similar to embodiments described in the '<NUM> patent. This second connection-level coding stage may be implemented before or after the encapsulation of frames into packets, leading to coding at the frame level or at the packet level, respectively. A separate decoding stage that mirrors the source's connection-level coding stage may be implemented at the destination connection endpoints.

Referring to <FIG>, an illustrative method <NUM> is used for coded multipath communication within a computer network (e.g., network <NUM> of <FIG>), according to embodiments of the present disclosure. The method <NUM> can be implemented, in full or in part, within a source (e.g., source <NUM> of <FIG>) or a destination (e.g., destination <NUM> in <FIG>).

At block <NUM>, a stream is initialized between the source and destination. This includes the destination sending a request for data (<NUM>) followed by a handshake (<NUM>) between the source and destination to setup at least one stream. While the example of <FIG> may refer to a single stream, it should be understood that multiple streams could be set up through the same handshake. The initialization handshake (<NUM>) also includes setting up one or more connections associated with the stream, where each up connection is associated with a specific path (e.g., a path <NUM> in <FIG>).

At block <NUM>, once the destination has established connections associated with the stream, it prepares and sends a data request to the source. The request includes an announcement of the maximum allowed DoF windows for the stream and its associated connections. This step includes an initialization of stream-level and connection-level DoF windows at the destination (<NUM>). As shown in <FIG>, block <NUM> can be repeated in a loop as additional data (e.g., new DoFs, frames, octets, etc.) are received. As new DoFs are received, the destination updates its stream-level and connection-level DoF windows (<NUM>). Step <NUM> involves decoding. The destination also sends frame ACKs or includes them in the data request to be sent to the source (<NUM>). The destination also computes new maximum DoF window sizes to be used by the source (<NUM>). The computed source DoF window sizes are included in the data request. This allocation (<NUM>) may involve multiple considerations such as code rate adjustments and flow control operations based on connection and path statistics, as previously discussed. The destination then sends the request to the source (<NUM>).

At block <NUM>, the source receives and executes the data request. This includes updating the source stream-level and/or connection-level DoF windows based on received ACKs (<NUM>). Based on the ACKs, the source removes frames that are no longer "useful" from the source's stream-level and connection-level DoF windows. A frame is deemed not "useful" if the destination has confirmed that the frame has been seen, received, or decoded, or if the frame is a coded representation of seen/received/decoded frames. If the DoF request includes new DoF window sizes, the source also adjusts its stream-level and connection-level DoF window sizes (<NUM>). The source proceeds to send data based on the request (<NUM>). The source may inject redundant coded packets into the transmission, at the level of the stream and/or at the level of a connection. In some embodiments, the source injects redundant coded packets based on the request from the destination (<NUM>).

At block <NUM>, the destination receives and processes the data (e.g., the DoFs, frames, octets, etc.). This includes updating the destination-side connection DoF windows (<NUM>) in a manner similar to that described above for step <NUM>. The destination collects connection performance information and use this information to update connection, path, and stream statistics (e.g., path/connection loss). The destination transfers the received DoFs to the stream-level DoF window (<NUM>) and updates the stream-level DoF window, which involves decoding received DoFs (<NUM>).

At block <NUM>, once the destination processes its received data, a decision can be made as to whether the stream should be terminated (block <NUM>) or whether additional data are required. If additional data are required, the method <NUM> may repeat from block <NUM>.

It will be appreciated that, using method <NUM>, as data transmission is carried out, the destination may adjust the source's maximum DoF window sizes at any time based on received DoFs, the flow control mechanism, and other available information (e.g., path/connection loss rates).

Note that the order of described operations within the main steps (i.e., <NUM>, <NUM>, <NUM>, <NUM>) is not specified and may be modified with the protocol implementation.

In certain embodiments, a data request sent by the destination can specify linear combinations of the data to be received (e.g., range/subset of frames to be combined, combine multiple frames from different streams, etc.). In some embodiments, the request may specify one or multiple paths over which coded frames will be transmitted. Frames produced by a single stream may be multiplexed across different connections over different paths. A destination may request the source to change the paths used by a stream by adjusting the maximum DoF window size, or by sending additional requests.

In some embodiments, a destination may request the sender to encode multiple streams together in order to have streams share their redundancy. The jointly encoded streams, in turn, may be transmitted through multiple connections across different paths. This may lead to robustness against individual path fluctuations. For example, using the same stream code rates, combining stream redundancies may lead to the ability to withstand larger burst losses on any individual path. Sharing stream redundancy also has potential security benefits, since an adversary needs to observe more streams and potentially more paths in order to recover any of the transmitted streams. It will be appreciated that sharing stream redundancy is optional and, in some embodiments, may be avoided in order to reduce complexity.

In some embodiments, coded frames from one or more streams can be recoded together using, e.g., a RLNC-based recoding technique. The recoding can occur at an intermediate node in the network, and then recoded frames can be transmitted to a destination node or another intermediate node in the network.

A destination may request the source to use one or more paths across which non-coded protocols will be used (e.g., one path uses coded QUIC, another path uses conventional QUIC). The receiver can negotiate with the sender which paths should be coded or non-coded and adjusts the encoding/decoding process accordingly. This mechanism allows for the coding endhosts to support legacy paths.

The subject matter described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or another unit suitable for use in a computing environment. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).

The processes and logic flows can also be performed by, and apparatus of the subject matter described herein can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

Claim 1:
A machine-implemented method for use at a destination node (<NUM>) for transferring data from a source node (<NUM>), the method comprising:
generating a stream-level degree of freedom, DoF, window (<NUM>) for a data stream (<NUM>);
establishing one or more connections (<NUM>) with the source node, each connection of the one or more connections being associated with one of one or more network paths (<NUM>) between the source node and the destination node;
generating one or more connection-level DoF windows (<NUM>) for the one or more connections;
sending (<NUM>, <NUM>, <NUM>) to the source node a request for the data stream, the request specifying at least a number of DoFs or frames to be transmitted across the one or more connections and a number of DoFs or frames to be transmitted for the data stream;
receiving (<NUM>) one or more coded frames through the data stream over the one or more connections;
in response to receiving the one or more coded frames:
removing (<NUM>) one or more frames from the stream-level DoF window or from the one or more connection-level DoF windows;
monitoring (<NUM>) performance metrics for the data stream and for the one or more network paths; and
based on the monitoring, sending (<NUM>) another request to the source node to change a size of a stream-level DoF window and a size of an at least one connection-level DoF window used by source node to generate coded frames; and
sending (<NUM>) to the source node a plurality of DoF acknowledgement, ACKs, wherein the plurality of DoFs ACKs include at least one stream-level DoF ACK and at least one connection-level DoF ACK, wherein at least one of the plurality of the DoF ACKs is included within the request for the data stream.