FR2958482A1 - Data stream managing method for transmitting device, involves stopping non-receiving indication message transmission to sending device by non-received parity data packet receiving device if retransmission of data packet is not required - Google Patents

Abstract

The method involves detecting data loss relative to a non-received parity data packet by a receiving device, and verifying whether a transmitter device retransmits the non-received parity data packet according to a criterion applied to flow source data used to generate non-received packet parity data. Transmission of non-receiving indication message toward the sending device is stopped by the non-received parity data packet receiving device if retransmission of the non-received parity data packet is not required. Independent claims are also included for the following: (1) a computer program comprising a set of instructions for implementing a method for managing a data stream transmitted by a transmitting device via a communication link (2) a computer-readable storage unit for storing a computer program comprising a set of instructions for implementing a method for managing a data stream transmitted by a transmitting device via a communication link (3) a receiving device comprising units for managing data stream transmitted by a transmitting device.

Description

Method of management by a receiver device of a data stream transmitted by a transmitting device, computer program product, storage means and corresponding receiver device 1. FIELD OF THE INVENTION The field of the invention is that of the networks of communication. The invention relates to a technique for transmitting a data stream by a transmitting device to a receiving device via a communication network. More specifically, the invention relates to a management technique of retransmission of parity data in such a network. 2. TECHNOLOGICAL BACKGROUND The Virtual Private Networks (VPN) technology makes it possible to communicate transparently, in real time and continuously, and in a secure manner, between individuals sharing a virtual private network. same area of interest while using unsafe but cheap internet network infrastructure. To transparently communicate and get rid of non-routable addresses, RPVs use a special encapsulation (called "tunneling" or "tunneling" in English) that creates what is called a communication tunnel (or more generally a link Communication). This operation consists of encapsulating a level A protocol (embedded or vehicular or passenger protocol) in a B protocol (transport or carrier protocol) using an encapsulation protocol C. Thus, the transport protocol B processes the protocol embedded A as if they were useful data. Figure 3, described in detail later, shows an example of encapsulation of packets in a level 2 VPN, that is to say in a level 2 tunnel (level 2 tunnel means that the embedded protocol A is an OSI Layer 2 protocol that describes the services offered by each of these layers and their interactions). For example, tunneling techniques are used to interconnect two home local area networks (hereinafter referred to as Local Area Networks) to create a virtual private network (or VPN) consisting of the union of the two. original LAN networks. A typical VPN configuration based on a tunneling technique is illustrated in Figure 1 (described in detail later). According to this technique, the communication link used to interconnect two LANs is a tunnel. Each LAN network includes an interconnection device, for example a tunnel endpoint (TEP), and a gateway. The tunnel is established between the tunnelheads, and each packet (also called frame) to be sent to the remote LAN is encapsulated by the tunnelhead connected to the local LAN and sent, via the tunnel, to the tunnelhead ( remote) connected to the remote LAN, which will de-encapsulate it and send it to the remote LAN. From the point of view of the LAN equipment interconnected by a tunnel, they are virtually connected to the same LAN. A communication between two devices via the tunnel is called end-to-end communication, or transient communication (in the sense of "embedded"), and the use of the tunnel is transparent to the equipment of the connected LAN networks.

Nowadays, there are VPNs having a tunnel formed by several carriers (or channels). Such VPNs are described in particular in patent document EP 2,020,799. A "multi-transport tunnel" is a tunnel that is made up of multiple carriers with distinct transport protocols. Each tunnel head then has a set of carriers with different characteristics, in order to adapt the transmission of data from one LAN to another to the application needs as well as to the variations of transmission conditions on the backbone network. (like Internet for example), between these LAN networks. In the state of the art, there are tunnels consisting of carriers implementing a transport protocol with data acknowledgment, such as for example the Transmission Control Protocol (TCP), and carriers implementing a transport protocol without data acknowledgment, such as for example the UDP protocol ("User Datagram Protocol" in English). The TCP protocol is an ARQ (Automatic Repeat Request) type protocol that is based on congestion and retransmission control mechanisms, and thus ensures the delivery of each packet to the destination. The UDP protocol is a much simpler and faster protocol, which does not take into account the order of the frames, and does not handle acknowledgment.

The UDP protocol then allows data delivery with controlled latency, however without any guarantee against data loss. In a tunnel, the UDP carrier is used to convey data (passenger stream) with high time constraints, such as audiovisual data. This audiovisual data is for example transmitted over a LAN according to the RTP protocol (for "Real-Time Transport Protocol", as defined by the RFC-3550 standard). Such data can not be transmitted via the TCP carrier of the tunnel, because in case of high error rate on the Internet, the TCP carrier would generate many retransmissions of packets, to ensure the delivery of data to the other tunnel head. Such packet retransmissions would result in significant variations in the end-to-end latency of the transported RTP stream. In addition, it should be noted that the flow control mechanism and the congestion control mechanism implemented by the TCP protocol cause, depending on the evolution of the network load, abrupt variations in the timing of the transmission of the signals. data.

Thus, one of the main problems related to this type of network, is to maintain a constant end-to-end transmission latency, while remaining robust with respect to the loss of data, in order to guarantee a perceived quality ("QoE For "Quality of Experience" in English) constant vis-à-vis the user. Indeed, the slightest interruption in the transmission of the stream (caused for example by a loss of data on the UDP carrier of the tunnel or by a delay of the TCP carrier leading to an obsolescence of the conveyed data) results in a degradation of the passenger flow . This is reflected for example at the user level by a cut of the listened musical piece or the displayed video. In the state of the art, there are several techniques for managing the retransmission of lost data packets According to a known approach, presented in the patent document US 2005/0111371, a data stream is transmitted according to a transport protocol combining data. parity and retransmission. FEC ("Forward Error Correction") parity data is inserted into the stream at regular intervals.

According to this known approach, the receiver device has a data loss detection mechanism. When a data loss of the stream is detected, the mechanism determines whether the associated FEC parity data (a FEC parity data for N data of the stream) allows the restoration of the stream data. If more than one stream data is lost for the same set of N data used to generate the FEC parity data, then a retransmission request must be made by the receiving device to the transmitting device. The receiving device further determines whether the retransmission of the stream data is necessary based on the time remaining before receiving the next parity data. However, such a system, by checking each data packet of the stream if a retransmission request must be made to the sending device, imposes an increased transmission latency compared to the use of a transport protocol without acknowledgment. neither retransmission. In addition, the use of a retransmission protocol over the entire stream requires significant memory resources, within the transmitter device in particular, to allow retransmissions of data on request of the receiving device.

In addition, such a system does not deal with retransmission management in the event of a loss of parity data. OBJECTIVES OF THE INVENTION The invention, in at least one embodiment, has the particular objective of overcoming these various disadvantages of the state of the art.

More specifically, in at least one embodiment of the invention, an objective is to provide a technique for transmitting a data stream by a transmitting device to a receiving device, which makes it possible to improve the overall efficiency of the transmission. end-to-end transmission of this stream, in terms of transmission reliability, in terms of transmission latency and in terms of bandwidth usage in the event of transmission errors. At least one particular embodiment of the invention aims to provide a technique that allows, in a network environment of the VPN type implementing a multi-transport communication, a reliable and fast delivery of a multimedia stream.

Another objective of at least one embodiment of the invention is to provide such a technique which is simple to implement and inexpensive. 4. DISCLOSURE OF THE INVENTION In a particular embodiment of the invention, there is provided a method of management by a receiving device of a data stream transmitted by a transmitting device via a communication link, the data of the stream data being transmitted to the receiver device by use of a transport protocol without data acknowledgment. The receiving device is such that it performs steps of: - detecting a loss of data relating to a packet of parity data not received by the receiving device, parity data having been transmitted by the transmitting device by use of a transport protocol with acknowledgment and retransmission of data, the parity data having been generated from source data of said stream; verifying whether it is necessary for the transmitting device to retransmit said parity data packet not received, as a function of at least one criterion applied to the source data of said stream used to generate the parity data of said non-received packet; if it is not necessary for the transmitting device to retransmit said parity data packet not received, to cancel transmission to the transmitting device of a non-reception indication message by the receiving device of the data packet parity not received.

Thus, it is proposed to transmit parity data on a carrier using a transport protocol with acknowledgment and retransmission of data (for example, the TCP protocol) to make reliable a flow of data transmitted on a carrier using a transport protocol without acknowledgment. data (for example, the UDP protocol). This benefits from the low latency of the transport protocol without data acknowledgment, such as the UDP protocol for example, and the robustness of the transport protocol with data acknowledgment, such as the TCP protocol, for example. In this way, the transmission latency of the data stream is improved compared to the state of the art. In addition, it is determined whether a retransmission of lost (not received) parity data is necessary (in the sense that this lost parity data is useful for the error correction mechanism), from a check result of criterion (s) applied to stream data transmitted according to the transport protocol without acknowledgment and used to generate parity data that has been lost. In the case where it is not necessary for the transmitting device to retransmit the lost parity data, no non-receipt of parity data indication message is sent to the transmitting device. Thus, the retransmission of the lost parity data is avoided, this retransmission having been deemed unnecessary. The use of the bandwidth between the transmitting device and the receiving device is therefore improved. According to an advantageous characteristic, said step of verifying whether it is necessary for the transmitting device to retransmit said packet of non-received parity data comprises the steps of: detecting that the source data of said stream used to generate the parity data of said packet not received have all been received by the receiver device; - decide that it is not necessary for the transmitting device to retransmit said parity data packet not received.

Thus, a retransmission of lost parity data is deemed unnecessary when all the source data of the stream (used to generate this lost parity data) conveyed according to the transport protocol without acknowledgment have all been received by the receiving device. According to another advantageous characteristic, said step of verifying whether it is necessary for the transmitting device to retransmit said packet of non-received parity data comprises the steps of: determining a time at which a given datum, among the source data of said stream used to generate the parity data of said non-received packet, must be obtained by the receiving device; detecting that the instant at which the determined data must be obtained by the receiving device exceeds an estimated time of reception of a retransmission of the parity data packet not received; - decide that it is not necessary for the transmitting device to retransmit said parity data packet not received.

It is proposed here to determine the time remaining before the lost parity packet has expired. The expiry time of the lost parity packet is the moment at which a given datum, among the source data used to generate the lost parity packet, must be obtained by the receiving device. Thus, once this moment of expiry has passed, if a retransmitted parity packet is received, then it is no longer useful because the corresponding source data is out of date. In other words, a retransmission of lost parity data is deemed unnecessary when the expiry time of this parity data has passed (ie, exceeds an estimated time of receipt of a retransmission of that data). parity). In a preferred embodiment, the estimated time of reception is determined from a round-trip time of the transmitted data according to the transport protocol with acknowledgment and retransmission of data. Thus, for example in the context of the implementation of the transport protocol with acknowledgment and retransmission of data (as a reminder, for the transport of the parity data and not the source data) using the TCP protocol, the value of the RTT time ( "Round trip time"), provided by TCP according to the RFC-793 standard, can be used to estimate the time of reception, which allows a simple and inexpensive implementation of this estimate. According to another advantageous characteristic, said step of verifying whether it is necessary for the transmitting device to retransmit said parity data packet not received comprises the steps of: detecting that the number of parity data (s) already received ( s) by the receiver device allows to reconstruct the source data of said stream used to generate the parity data of said packet not received; - decide that it is not necessary for the transmitting device to retransmit said parity data packet not received.

Thus, retransmission of lost parity data is deemed unnecessary when the receiving device has already received a sufficient number of parity data to enable it to recreate the lost source data. Advantageously, the receiving device first performs a step of intercepting said non-receiving indication message from the parity data packet not received, and the step of canceling transmission to the transmitting device of a Non-receipt indication message comprises steps of: - deleting said intercepted non-receiving indication message; generating a stuffing packet that replaces the non-received parity data packet; transmitting the generated stuff packet to an acknowledgment processing module so as to obtain a receive indication message of said non-parity data packet; received. Thus, it is proposed to delete the intercepted non-receipt indication message. It should also be understood by this expression that one can simply delete the indication of non-reception of a frame containing several messages. For example, according to the TCP protocol, it is possible to have, in a frame transmitted by a device A, an acknowledgment for application data (or sources) received from a device B and application data (or sources) that the Device B transmits to Device A. It is proposed here to substitute the lost parity packet with a stuffing packet that will take the place of the parity data packet not received in the transmission control performed by the Acknowledgment Processing Module. . For example, it is possible to replace lost parity data with padding data. The transmission of this stuffing packet to an acknowledgment processing module has the effect of triggering an acknowledgment of the parity data which has not been received. This stuffing packet generation mechanism thus makes it possible to avoid blocking the carrier implementing the transport protocol with acknowledgment and retransmission. It will be noted that the acknowledgment that is ultimately transmitted to the transmitting device causes the latter, on receipt of this acknowledgment, to perform no retransmission of data. Preferably, the stuffing packet has the same identifier (sequence number) and the same size as the non-received parity data packet. Thus, in the context of the implementation of a transport protocol with acknowledgment and retransmission of data in connected mode, such as the TCP protocol, the stuffing packet makes it possible to maintain the expected alignment of the data.

Advantageously, if it is necessary for the transmitting device to retransmit said non-received parity data packet, the receiving device performs a step of transmitting said non-receiving indication message of the non-received parity data packet to the transmitting device.

Thus, a retransmission of data can take place. In a preferred embodiment, a predefined size encoding window is applied to the source data used to generate the parity data of said non-received packet, and each parity data of said non-received packet has the same identifier as a source data. predetermined position in the encoding window.

Thus, the relationship between source data and parity data being predefined, the implementation of the management method remains simple. In a preferred embodiment, the communication link is a communication tunnel interconnecting local area networks, and each of the transmitter and receiver devices is a tunnel head belonging to a respective local area network. The source data is generated by a source terminal device of a said local network and is intended for a terminal device destination of a said separate local network. In another embodiment, the invention relates to a computer program product which comprises program code instructions for carrying out the aforesaid method (in any of its various embodiments), when said program is running on a computer. In another embodiment, the invention relates to a computer readable storage means storing a computer program comprising a set of computer executable instructions for carrying out the above method (in any one of its different embodiments).

In a particular embodiment of the invention, there is provided a receiver device comprising means for managing a data stream transmitted by a transmitting device via a communication link, the data of the data stream being transmitted to the receiving device by use a transport protocol without data acknowledgment. The receiving device is such that it comprises: means for detecting a loss of data relating to a packet of parity data not received by the receiving device, parity data having been transmitted by the transmitting device by use of a transport protocol with acknowledgment and retransmission of data, the parity data having been generated from source data of said stream; means for verifying whether it is necessary for the transmitting device to retransmit said parity data packet not received, as a function of at least one criterion applied to the source data of said stream used to generate the parity data of said non-received packet; means for canceling transmission to the transmitting device of a non-reception indication message by the receiving device of the parity data packet not received, said means for canceling being activated if the means for verifying detect that it is not necessary for the transmitting device to retransmit said parity data packet not received. Advantageously, the receiver device comprises means for implementing the steps of the management method as described above, in one of its various embodiments. 5. LIST OF FIGURES Other features and advantages of the invention will appear on reading the following description, given by way of indicative and nonlimiting example, and the appended drawings, in which: FIG. 1 schematically illustrates a configuration of a virtual private network for the implementation of the invention according to a particular embodiment; FIG. 2 schematically illustrates an exemplary layered model of a tunnel head in which the method according to a particular embodiment is implemented; FIG. 3 schematically illustrates an exemplary format of an Ethernet frame carrying a level 2 tunnel packet; - Figure 4 schematically illustrates the functional blocks of a transmitter block included in a tunnel head, according to a particular embodiment of the invention; FIG. 5 diagrammatically illustrates the functional blocks of a receiver unit included in a tunnel head, according to a particular embodiment of the invention; FIG. 6 represents a flow diagram of a data retransmission management algorithm according to a particular embodiment of the method according to the invention, implemented by the receiver block of FIG. 5; FIG. 7 illustrates an example of data packet formats exchanged between two tunnel heads; FIG. 8 schematically illustrates an example of a storage table managed by a flow scheduler (included in the receiver block of FIG. 5); FIG. 9A represents a flowchart of an algorithm for transmitting a data stream according to a particular embodiment of the method according to the invention, implemented by the transmitter block of FIG. 4; FIG. 9B shows a particular embodiment of an algorithm implemented within a marking module (included in the transmitter block of FIG. 4); and FIG. 9C shows a particular embodiment of an algorithm implemented within a filtering module (included in the receiver block of FIG. 5). 6. DETAILED DESCRIPTION In the remainder of the description, one places oneself in the case where the communication network implements a communication link which is a tunnel, enabling sending and receiving devices to exchange multimedia data. Of course, the present solution can be applied to any other type of communication link between transmitter and receiver devices, for example transmitting and receiving devices communicating on the same LAN ("Local Area Network" in English). For the sake of simplification of the description, it will be considered later that the length of the packets of parities generated is equal to the value MSS (for "Maximum 30 Segment Size" in English) of the TCP carrier. It is recalled that the MSS parameter 10 corresponds to the largest amount of useful data that can be supported by a single TCP segment. FIG. 1 diagrammatically illustrates, according to a particular embodiment of the invention, a virtual private network (VPN) configuration implementing a tunnel 100 of communication between a first local tunnel head 101 and a second remote tunnel head 102, through a communication network 107, such as the Internet for example. This tunnel 100 interconnects a first communication network 103 and a second communication network 104, also called respectively LAN A 103 and LAN B 104. The first LAN A 103 and the second LAN B 104 each have an Internet access equipment. broadband gateway type home Internet (or "Home Gateway" in English) (referenced respectively 105 and 106), which can incorporate a firewall (or "Firewall" in English) (referenced respectively 105a and 106a), type of equipment PC 109 and 111 servers 110 and 113 for storing and sharing digital media (audio, video, photo), as well as digital media playback equipment 108 and 112. A tunnel head can be a piece of equipment dedicated (as shown in Figure 1) or be integrated into an audiovisual equipment such as a digital TV. It can also be present in a PC-type equipment in the form of a program performing the functions associated therewith. Once the tunnel 100 has been established, the devices 108, 109, and 110, connected to the first LAN A 103, are capable of communicating with the devices 111, 112 and 113 connected to the second LAN B 104. For example, the client local 108 connected to the first LAN A 103 network may communicate, in a transparent manner, with the local server 113 connected to the second LAN B network 104. In this Figure 1 is shown a simple communication network with a single tunnel, but it is of course that one and the same LAN can have several tunnel heads and / or that the same tunnel end can manage several tunnels (to as many tunnel heads) to interconnect a first LAN to several other networks LAN. In addition, for the sake of simplification, infrastructure equipment in the Internet network such as Internet routers has not been represented. With reference to FIG. 2, the path of an Ethernet frame originating from one of the devices 108, 109, 110, connected to the first LAN A 103, and entering the tunnel 100 to be routed to second LAN B network 104. To do this, we use a layered model describing the protocol layers necessary for the implementation of this tunnel 100. In this model are not represented the protocol elements necessary for the functions other than the implementation. implementation of the tunnel. For example, the protocol elements associated with a UPnP architecture (for "Universal Plug and Play") are not represented when a first tunneling head 101 is integrated in a UPnP equipment. The first tunnel head 101 comprises an Ethernet physical interface 235 which delivers the Ethernet frames from the equipment 108, 109, 110 to the link layer 230 for routing: to the IP network layer 225, for the Ethernet frames to the equipment. with the tunnel end, or towards the bridge layer 240, for the other Ethernet frames. The bridge layer 240 performs the typical operations of an Ethernet bridge such as filtering the Ethernet frames and relaying these frames to the appropriate output Ethernet port (s). On the bridge are attached an Ethernet interface 230 and at least one virtual interface 245 simulating an Ethernet controller. A virtual interface 245 is created for each tunnel instantiated by the application 200 to which it delivers the Ethernet frames that must pass on the tunnels respectively instantiated. In a general manner, the encapsulation protocol of the tunnel represented by the application 200 carries out the operations necessary for the implementation of each tunnel, among which we find in particular the configuration, the filtering and the encapsulation, it is ie the formation of a tunnel packet, and the extraction of a frame. In a particular embodiment, the application 200 implements steps of the method according to the invention which are detailed hereinafter in relation to FIGS. 6 and 9 (A, B, C). The frames received from the virtual interface 245, after processing by the application 200, are delivered in the form of a packet through an application interface 205 (or "socket" in English) to a reliable transport protocol TCP 210 or unreliable UDP 220. In the case where the reliable TCP transport protocol 210 is selected, the Ethernet frames are directed to the ARQ hybrid tunnel protocol 215. The ARQ hybrid name is used to designate a protocol using both a retransmission mechanism ARQ type, and error correction mechanisms such as sending parity packets (using, for example, a Reed-Solomon protocol) for reconstructing lost or errored packets. After processing by a transport protocol to form a tunnel packet, it is transmitted to the network layer 225. The IP datagram thus formed with the tunnel packet can then be transmitted over the LAN through the connection layers 230 and the physical layer 235. , to then be transmitted over the Internet through the gateway 105. The reception of a frame from the tunnel 100 will follow in the tunnel head 101 the reverse path to that presented above. Note that in the case where the ARQ hybrid protocol 215 is implemented outside a tunneling context, the bridge layer 240 and the virtual interface 245 are deactivated. In this case, the application layer 200 represents any application layer according to the OSI model, that is to say, for example, conventional applications of the HTTP, FTP, etc. type. Thus, the hybrid protocol ARQ 215 can apply to any communication from a first device to a second device. FIG. 3 shows an exemplary format of an Ethernet frame 360, for example passing over the first LAN A 103 of FIG. 1 between the first tunneling head 101 and the home gateway 105. This Ethernet frame 360 can be transmitted to the second LAN B network 104 via the Internet or to be received from the second LAN B 104 network via the Internet. This Ethernet frame 360 comprises an Ethernet header field 361, a first IP datagram 362 itself carrying a level 2 tunneling packet 350, and an FCS field 363 (for "Frame Check Sequence" in English, or "sequence frame control "in French).

The tunnel packet 350 comprises four parts: a header field of the transport protocol 351 (namely TCP or UDP in this example); a header field of the encapsulation protocol 352 (namely L2TP in this example, which is described in particular in the following document: "IETF RFC-3931," Layer two tunneling protocol - version 3 (L2TPv3) ", J. Lau and ail, March 2005 "- an embedded protocol header field 353 (i.e. Ethernet in this example), and - a payload field 354, which includes a second full IP datagram if no fragmentation has been operated during its transit from the source equipment .. Figure 4 schematically illustrates the functional blocks of a transmitter block included in the tunnel heads according to one embodiment of the invention.

Each tunnel end (PET) 101 or 102 includes a transmitter block 410 for transmitting data via the multi-transport tunnel 100 (i.e. via a tunnel comprising a plurality of carriers each using a transport protocol, such as for example a TCP 100A carrier and a UDP carrier 100B). The different protocol layers presented in relation to FIG. 2 are represented here in a simplified manner, for the sake of legibility of the representation. Similarly, gateways 105 and 106 are omitted. In addition, the data flows conveyed via the tunnel 100, but to which no error correction data is added in the context of the particular embodiment of the invention, are not represented (this is the case by way of example). example for the streams integrally transmitted on the carrier UDP 100B without transmission of data of redundancy (or of parity) on the carrier TCP 100A). The following description relates only to the transmission of a data stream 401 via the tunnel 100, from the tunnel head 101 to the tunnel head 102. A similar description applies for a flow transmission, in the opposite direction, that is to say from the tunnel head 102 to the tunnel head 101.

It should also be noted that only one data stream 401, transported through tunnel 100 from tunnel head 101 to tunnel head 102, is considered for illustrative purposes. However, several flow-like streams 401 can simultaneously benefit from the advantages of the present invention. The transmitter block 410 of the tunnel head 101 receives as input a stream 401, originating from the LAN network A 103, and is in charge of transporting the data of this stream 401 via the tunnel 100, taking advantage of the TCP 100A carriers and UDP 100B. In the rest of the description, the transport of a stream 401 is carried out via the UDP carrier 100B and the parity data transport associated with this stream 401 is carried out via the TCP 100A carrier. In the embodiment illustrated in FIG. 4, the transmitter block 410 of the tunnel head 101 comprises the following elements: a decision-making module 412, in charge of determining parameters of an error correction code (or parameters); 'parity encoding). The parameters of the error correction code are a number M of parity packets generated for a number K of packets of the stream 401. In a first particular embodiment (described in detail below), the error correction code is a Reed-Solomon type code applied at the packet level. In a second particular embodiment (described in detail below), the error correction code is a code based on an application of EXCLUSIVE OR (XORs) applied at the packet level. The decision-making module 412 is in charge of routing each of the packets of the stream 401 of the LAN 103 to one of the carriers of the tunnel 100; an encoding module 415, in charge of generating (or encoding) parity packets from the stream 401 according to the parameters of the error correction code determined by the decision-making module 412; packagers 413 and 414, each dedicated to a carrier of the tunnel 100, in charge of encapsulating the data coming from the encoding module 415; an interface port 411 representing the IP network layer 225; a marking module 416, in charge of valuing a "PCL" field (for "Parity Code Localization") contained in a parity packet 750, the format of which is described in detail below in relation with FIG. 7.

The decision module 412 comprises a statistics receiver (not shown) receiving information relating to transmission conditions via the tunnel 100, and allowing the module 412 to determine the parameters of the error correction code necessary for the encoding of the packets. parity. These statistics obtained make it possible to determine the proportion of parity data to be sent to make the flow a priori robust to losses. The operation of such a receiver of statistics is described in particular in patent document EP 2,020,799. The encoding module 415 encodes a first set of K packets of the stream 401 (hereinafter referred to as the K-size encoding window) to obtain a second set of M parity packets. It should be noted that, in a particular embodiment of the invention, the encoding module 415 acts at the packet level ("at packet level" in English), that is to say that the size considered for the encoding and parity decoding corresponds to the size of the useful data conveyed via the carriers of the tunnel 100. This gives a total number N of packets, such as N = M + K, to be transmitted via the tunnel 100. The decision module 412 then hands the M parity packets to the TCP 100A carrier via the packager 413 and the K packets from the stream 401 to the UDP carrier 100B via the packager 414. Thus the transmission of the packets of the stream 401 via the UDP carrier 100B of the tunnel is made reliable by the transmission of parity packets via the TCP 100A carrier of the tunnel. In a particular embodiment of the invention, the packets of the stream 401 have a MTU size (for "Maximum Transmission Unit" in English) allowing direct insertion of the data packets formed in the payload field 354 (described in relation with Figure 3) during encapsulation for transport on the UDP 100B carrier. In the case where the decision module 412 uses a Reed-Solomon error correction code applied at the packet level, the coding is performed using a matrix. The K packets from the stream 401 are arranged in such a way that each of them forms a column of the matrix, each element of the matrix then representing a symbol. A Reed-Solomon C error correction code (N, K) is then applied to each row of the matrix to manage at least one symbol (according to the C (N, K) applied) of parity. A matrix (or a vector according to the applied C (N, K) code) of parity symbols is then obtained, each column forming a parity packet. Reciprocally, the decoding operation is performed by arranging the received packets so that each of them forms a column of the matrix, each element of the matrix then representing a received symbol. A Reed-Solomon type decoding, corresponding to the C (N, K) code applied, is then applied to each row of the matrix, so as to obtain a resulting matrix comprising the original symbols.

The K packets of the encoding window form the columns of the resulting matrix. In the case where the decision-making module 412 uses functions of OUEXCLUSIFs (XORs) for the construction of a parity packet, the K packets of the stream 401 are combined in the following manner: either "pl, p2, ..., pK "K packets (size" m ") of the stream 401 and" "the value of the ith bit of the packet" pi "(with j = 1, ..., k); either "r" the parity packet to be built and "r" the value of the ith bit of the parity packet; - then: K r1 = p ~ (mod 2) Vi E 1, .., m} j = 1 Thus, it suffices to perform the bitwise sum on the K packets received to recover the lost packet among the K + 1 packs. Such an operation is simple to implement on hardware ("hardware" in English) embedded. This operation requires a processing cycle (or CPU cycle for "Central Processing Unit" in English) by transmitted code word, which induces a very low processing time.

FIG. 5 diagrammatically illustrates the functional blocks of a receiver unit included in the tunnel heads according to one embodiment of the invention. Each tunnel head 101 or 102 includes a receiver block 420 for receiving data via the tunnel 100. The receiver block 420 of the tunnel head 102 receives the data from the tunnel 100, and restores, on the LAN B 104 network, a stream 402 of data corresponding to the original stream 401 (for example, the stream 402 is identical to the stream 401 if there has been no loss on the Internet) In the embodiment illustrated in FIG. 420 of the tunneling head 102 comprises the following elements: an interface port 411, representing the IP network layer 225, on which the encapsulated packets transmitted by the transmitting device 101 are received, deblockers 421 and 422 each. dedicated to a carrier of the tunnel 100, in charge of de-encapsulating the data coming from the tunnel 100: a temporary storage unit 423, responsible for reordering the data of the stream 401 and for associating therewith the received parity data, thanks to data packet formats described below in connection with FIG. 7. The temporary storage unit 423 makes it possible to temporarily store the packets received via the TCP 100A and UDP 100B carriers. This temporary storage allows time for parity packets associated with UDP packets to be received via the TCP 100A carrier. Indeed, the TCP 100A carrier has a higher latency than the UDP carrier 100B, and the parity packets are issued after the transmission on the UDP 100B carrier data packets of the corresponding encoding window. In addition, this temporary storage is used by a stream scheduler 425 (described below) to ensure a small variation in latency or jitter (jitter) for the streams transmitted via the UDP 100B carrier. Finally, this temporary storage of TCP data packets (without parity) allows the scheduler 425 to offer a higher transmission priority to the UDP packets; a frame regenerator 424, in charge of reconstructing the frames of the stream 402 obtained at the output of the tunnel, from the data of the stream 401 transmitted via the UDP carrier 100B and parity data transmitted via the TCP 100A carrier and stored in the 423. The frame regenerator 424 comprises a correction module 4241, in charge of reconstructing the data packets of the stream 401 despite the data losses occurring during the transmission via the tunnel 100, and this, depending on the encoding window (parameters of the error correction code) determined by the decision-making module 412. The parameters of the error correction code applied are common and known to the encoding module 415 and the frame regenerator 424. These can be predefined and stored in read-only memory, or exchanged between the transmitter 410 and receiver 420 blocks, for example in a control session; A frame retransmission management module 426 comprising the following elements: a TCP packet filter module 4261 (hereinafter referred to as TCP filter 4261), in charge of: for the packets originating from the TCP layer 210, and to the interface port 411, determine if a (packet of) acknowledgment is representative of a loss of data, and potentially delete such an acknowledgment according to conditions determined by an optimization module retransmission 4262 (described below); For the packets coming from the interface port 411 and destined for the TCP layer 210, locating the TCP sequence number carrying a piece of parity data, and updating a index table 4264. For this, following the receiving a TCP message of the type described in FIG. 7, the TCP filter 4261 informs the index table 4264 with: • associations between TCP sequence numbers and SBN encoding window number (for "Source Block Number "); • associations between TCP sequence numbers and the presence of parity data; the retransmit optimization module 4262 is responsible for determining according to information from the scheduler 425, the index table 4264 and the temporary storage unit 423, if a retransmission of parity data is useful or not. In the event that this retransmission proves to be useless, the optimization module 4262 controls the filtering of the duplicated acknowledgments "DUP ACK" (via the TCP filter 4261), and controls the generation of a fictitious packet, making it possible to avoid block the TCP carrier. A dummy packet is a packet whose sequence number and size correspond to the lost parity TCP packet, and contains stuffing data. Indeed, when a packet is lost, it blocks the carrier because until this packet is not received, no other packet will be transmitted by the receiving device; A TCP packet generator module 4263 in charge of generating and transmitting a dummy packet (as defined above). As will be seen below with FIG. 7, a dummy packet has a flag "F" (for "Flag FEC") at 1, which means that the packet considered is a parity packet, and "SBN" fields. (for "Source Block Number") and "ESI" (for "Encoding Symbol Identifier") to 0. Such a fictitious package contains a useful data field filled with padding data (English padding data), necessary to guarantee the correct length of the frame; the flow scheduler 425 is responsible for the transmission of data on the LAN 104, based on the packets from the TCP and UDP carriers. The flows transported by the UDP carrier, having a strong time constraint, are transmitted on the B 104 LAN network regularly, and without excessive latency. TCP packets are issued when the scheduler can do this without penalizing the UDP streams. For example, for streams 401 and 402 of the RTP type, the time stamp ("timestamp" in English) included in the packet RTP is used to effect the timing of the stream 402 by the scheduler 425, so as to maintain a jitter ( "Jitter" in English) quasi-zero, that is to say an inter-packet delay quasi-constant. It is also possible to use a predefined constant time interval. If at the moment when a packet has to be sent, to guarantee zero jitter, it is not available, the data is considered out of date, and the first packet available for this stream is sent (the first packet being the packet of which the expiry date is closest to the current date). When the last packet of an encoding window (corresponding to an encoding window SBN number) is sent (or out of date), all the expiry information associated with the packets of this encoding window are deleted from the encoding window. 800 storage of the scheduler and the information of a new encoding window are pre-filled. These deletion and pre-intelligence operations are described in detail below in connection with FIG. 8.

In the rest of the document, the algorithms of one embodiment of the invention are described according to an implementation on a tunnel head 101 or 102. The transmitter block 410 and the receiver block 420, included in each tunnel head , each are carried out indifferently: • on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or • on a dedicated computing machine (for example a set of doors as an FPGA or an ASIC).

In the case of an embodiment of a module (transmitter or receiver block) on a reprogrammable calculation machine, the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (Such as for example a floppy disk, a CD-ROM or a DVD-ROM) or non-removable, this storage medium being partially or completely readable by a computer or a processor. FIG. 6 represents a flowchart of a data retransmission management algorithm according to a particular embodiment of the method according to the invention, implemented by the receiver block 420 of the tunnel head 102. In this particular embodiment , the receiver unit 420 stores the sequence number of the TCP data packet of the last acknowledgment (from the TCP layer 210), denoted "L_ACK" thereafter. The receiver unit 420 also stores a count value "Nb_Ack" supplied by a counter responsible for counting the acknowledgment messages intercepted by the receiver unit 420. As will be seen below, this number "Nb_Ack" makes it possible to determine whether a current acknowledgment is significant of a loss of data carried on the TCP 100A carrier. The receiver block 420 performs the steps of the algorithm of FIG. 6 (described below), each time the TCP filter 4261 intercepts an acknowledgment message (also hereinafter called current acknowledgment) of a data packet. TCP received. This acknowledgment message comes from the TCP layer 210.

In step 610, a test is performed to determine whether the current acknowledgment is a duplicate "DUP ACK" acknowledgment. For this, it is checked whether the current acknowledgment has already been sent by the receiver. More specifically, if the sequence number of the TCP data packet of the current acknowledgment is different from the L_ACK sequence number of the TCP packet of the last acknowledgment, then the current acknowledgment is not a DUP ACK duplicate acknowledgment, and proceed to step 680. On the other hand, if the current acknowledgment is a duplicate acknowledgment DUP ACK, then the count value Nb_Ack is incremented by one unit, then step 620. At step 620 , a test is performed to determine whether the current acknowledgment (which is therefore a DUP ACK duplicate acknowledgment) is indicative of TCP packet loss. For this, at this step 620 the count value Nb_Ack is compared with a threshold value, synonymous with a loss (generally this value is equal to 3 in the standard TCP layers). If the count value Nb_Ack is less than the threshold value, then there is no packet loss, and proceed to step 690. If the count value Nb_Ack is greater than or equal to the threshold value then there is a packet loss, and proceed to step 630. In step 630, a test is performed to determine if the lost packet (and in this sense not received) is a parity packet, c. that is, a packet containing parity data associated with source data of the stream 401. For this, the index table 4264 is consulted. This table is updated by the TCP filter 4261 when it receives the data. TCP data. If the lost packet is a parity packet, then proceed to step 640, otherwise proceed to step 690. In step 640, the index table 4264 is parsed to identify the UDP packets of the encoding window (each UDP packet containing source data of stream 401) that is associated with the lost parity packet. For this, the table 4264 is traversed, in order to find the record corresponding to the sequence number of the TCP packet lost. This record contains the number of the encoding window (SBN), this makes it possible to identify the associated UDP packet. Then, at this same step 640, the temporary storage unit 423 is analyzed so as to determine, among the UDP packets of the identified encoding window, the number of UDP packets that have not been received ( also referred to as missing UDP packets). For this, the storage unit 423 is interrogated (for example by exhaustive browsing of all of these records, made possible by the fact that this temporary storage area contains only a small number of records), to obtain the list of UDP packets, (identified during the analysis of the 4264 table), which have already been received and unpacked by the de-packager 421. Then, the step 650 is performed. In step 650, the receiver block 420 determines the time remaining before the lost parity packet has expired. The expiry date of a parity packet is the date on which the last of the missing UDP packets (from the encoding window identified in step 640) is to be transmitted on the second LAN B 104 by the scheduler 425. This information is obtained by querying the storage table 800 of the scheduler 425 (described in detail in Figure 8). Note that once this expiry date has passed, if a parity packet corresponding to the encoding window identified is received, then it is no longer useful because the missing UDP packets are out of date. In this case, it is therefore useless to reconstruct them. In step 660, a test is performed to determine whether the lost parity packet is useful or not. For a parity packet to be useful, the following two conditions must be satisfied: - the expiry date of the lost parity packet (determined in step 650) must not exceed the current date plus a time retransmission of the lost packet. This retransmission time is equal to about an RTT time increased by a security value that can be parameterized, for example, by the user, or generally set at twice the value of the jitter found on the TCP 100A carrier. Indeed, if a request for retransmission of a packet is sent (in the form of three DUP ACK duplicate acknowledgments) by the receiver, then in the best case the receiver will receive the retransmission after a RTT time. Therefore, if the expiry date of the lost parity packet exceeds the current date plus the retransmission time, this packet will no longer be useful because all source data of stream 401 associated with this parity packet will have been issued. , or ignored (if out of date) by the scheduler 425; - the number of UDP packet (s) missing must be such that the number of parity packet (s) already received (s) is not sufficient to reconstruct all the missing packets. If both of the above conditions are true, then retransmission of the not received parity packet is useful, and step 690 is performed. Otherwise, the retransmit optimization module 4262 prevents this retransmission by performing step 670.

In step 670, the current packet is modified to indicate that it does not contain a valid acknowledgment number (to do this, the ACK bit of the TCP header is set to 0). Then, the modified packet is sent to the TCP filter 4261, which is responsible for transmitting it to the interface port 411. It should be noted that when the current TCP packet does not contain data, but only an acknowledgment, this packet is then simply destroyed. Then, at this same step 670, a fictitious packet (as defined above) is generated. This dummy packet is then sent to the TCP layer 210. This dummy packet contains stuffing data, so it is not used by the scheduler 425. In step 680, the sequence number L_ACK is updated with the sequence number of the TCP data packet of the current acknowledgment, and the count value Nb_Ack of the iteration counter is reset to O. Then, proceed to step 690. In step 690, the TCP filter 4261 transmits to the interface port 411 the current packet without any modification. Thus, at this step 690, an acknowledgment of the lost packet is issued. Note that if the parity data is not systematically aligned, then using a list of parity data start sequence numbers would determine in step 630 the packages containing parity information. complete, or the end of a parity information. This sequence number list of TCP packets containing parity data may for example be sent as an option for each TCP packet. Since the length of the parity data is known (fixed), it can then be deduced by difference with the sequence number of the last received packet (determined by reading the table 4264, or interrogation of the TCP layer 210), if the lost packet contains parity info, and / or application data (data other than those provided by ARQ 215 hybrid tunnel protocol). These packets are then potentially not retransmitted. In this case, in step 670, the current packet is modified by indicating in the acknowledgment sequence number the sequence number of the first data byte of the lost packet (equal to the parity packet start sequence number). plus length, incremented by one, of the parity packet). Then, a TCP packet with the sequence number of the lost packet and a length corresponding to the size of the parity data present in the lost packet is transmitted to the upper layer (difference between the number sequence of the first data byte of the lost packet, and the sequence number of the lost packet). FIG. 7 illustrates an example of data packet formats exchanged between the tunnel head 101 and the tunnel head 102 via the tunnel 100. For example, an encapsulation of data according to the L2TP protocol (according to the RFC standard). 3931) is used. The format of the frames supporting such an encapsulation can be preserved for any communication implemented outside a tunneling context, ie the transported useful data 723, 753 are no longer temporary Ethernet frames but local application data. It should be noted that, in order to be able to apply a FEC ("Forward Error Correction") error correction mechanism, compatible between a coding module 415 and a correction module 4241, the parameters of the error correction code used (in particular the parameter K of the number of source packets in an encoding window and the parameter M of the number of parity packets generated) are exchanged beforehand in the context of a tunnel control session (not represented). In a particular embodiment, the control session of the multi-transport tunnel is established on the TCP 100A carrier. Thus, in order to be able to apply an error correction mechanism of the FEC type, the encoding module 415 supplies the correction module 4241 with the parameters of the error correction code used (in particular the parameters M and K, and the type of correction code error) during the control session. In a particular embodiment, the exchanged information relates to the object FEC OTI (for "Forward Error Correction Object Transmission Information"), which is described in particular in the standardization document RFC-5052 ("FEC Building Block"). An example of an encapsulation format 720 of a data packet (from the stream 401) according to the L2TP protocol on a UDP carrier 100B is presented below, in connection with FIG. The encapsulated data packet 720 according to such a protocol more precisely comprises: a first portion of header 721 of L2TP session encapsulation; a second header portion 722 of encapsulation specific to the transport of data packets, comprising the following fields: a "Sequence Number" field containing a sequence number value SN specific to each L2TP data packet. This SN sequence number is used for the purposes of operations performed upon receipt of the data packets. For example, such a sequence number SN is used during a re-ordering operation of the data. In the case of a particular embodiment of the invention, the sequence number SN is used to group the packets of the stream 401 of the same encoding window (of size K); * a flag "F" (for "Flag") indicating whether the useful data encapsulated in a third part 723 have been the subject of a parity encoding by the encoding module 415. It is now presented, still in relation with FIG. 7, an exemplary encapsulation format 750 of a parity packet (generated by the encoding module 415) according to the L2TP protocol on a TCP carrier. The parity packet encapsulated 750 according to such a protocol more precisely comprises: a first header session 751 portion L2TP encapsulation; a second header portion 752 of encapsulation specific to the transport of the parity packets, comprising the following fields: * a flag "F" (for "Flag FEC") indicating whether the payload data constitutes parity data ( F equal to 1 if the payload is parity data, 0 otherwise); * an "R" flag (for "Retransmit FEC") indicating whether the parity data transported are from a retransmission according to hybrid protocol ARQ 215; * a "SBN" (Source Block Number) field containing an encoding window number, used to identify the K packets encoding window to which the encapsulated packet is associated; an "Encoding Symbol Identifier" (ESI) field containing a coding symbol identifier, used to identify the packets of the stream 401 used for encoding the parity packets; * a "PCL" field (for "Parity Code Localization") containing a marking used to locate packets / parity data in the transport stream of the TCP 100A carrier. The temporary storage unit 423 of the receiver unit 420 is organized as a linked list of elements, called nodes, where each node groups together a set of user data packets 723 or parity data 753 relating to the stream 401, stamped by the same SBN number of encoding window. Since the parameter K of the number of source packets in an encoding window and the parameter M of the number of parity packets generated are known in advance from the transmitter and the receiver, and because the TCP 100A carrier has a higher latency than the UDP carrier 100B, then every time a TCP packet containing parity data 753 is received, the receiver block 420 rearranges the payload 723 (depending on the sequence number SN carried by the UDP packets in their second header portion 722) in relation to the encoding window SBN number. In other words, for a useful data item 723, this payload 723 is attached to the corresponding parity data item 753. Then, the UDP 720 packets lost on the network are identified. In case the decision module 412 uses a Reed-Solomon error correction code applied at the packet level, the ESI field corresponds to the index of the generated parity packet. For the same encoding window of K packets of the stream 401, each packet 750, carrying a parity data Mi, has a different field ESI, according to the index i of generation, respecting i <M. The value of the SBN field is identical for parity packets of the same encoding window. The value of the SBN field is incremented by one unit at each new encoding window. In case the decision-making module 412 uses functions of OUEXCLUSIFs (XORs) for the construction of a parity packet, that is to say in the case where an EXCLUSIVE-OR (XOR) operation is applied between the K packets of the stream 401, the ESI field indicates the scope of the EXCLUSIVE-OR (XOR) operation on an encoding window of K packets of the stream 401. For example, at each bit of the binary representation of the value of the ESI field is associated with a packet of the encoding window, and the value of this bit indicates whether the associated packet (among the K packets) was used by the error correction code (bit 1 if so, bit to 0 otherwise). The PCL field of the second header portion 752 identifies the position of the parity data carried on the TCP 100A carrier with respect to the conventional data carried on this TCP 100A carrier. Structure 760 details the formatting of the PCL field. The unit represented by a bit corresponds to an MSS size offset in the TCP sequence numbers (relative to the current received packet). The bits represented represent TCP sequence numbers that can not be assimilated to TCP packets. Indeed, a TCP packet can convey retransmissions, which does not allow to maintain an alignment between packet number and sequence number. The PCL 760 field reads from right to left, and has two parts: - for bits 0 to 15, the value of each bit of this first 16-bit subfield indicates the location of the coding windows (ie that is, a SBN number change) in the TCP stream from the current packet (represented by bit 15). The index of the bit at 1, in the reading direction mentioned above, gives the number of data group of size MSS between the beginning of the encoding window concerned and the current packet (bit 15); for bits 16 to 31, the value of each bit of this second 16-bit subfield indicates the location of a start of parity data (i.e., the first byte of packet 750) in the TCP stream from the current packet (represented by bit 31). The index of the bit at 1, in the reading direction mentioned above, gives the number of data group of size MSS between the preceding transmitted parity data and the current packet (bit 31). The correlation of the first and second subfields makes it possible, on the one hand, to identify the TCP sequences (with a granularity of MSS bytes) containing parity data, and on the other hand to identify the encoding window SBN number. for each of these parity data. For the example of the PCL field 760 illustrated in FIG. 7, the following information is read: the current TCP packet does not contain a packet 750 carrying parity data (bit 31 to 0) nor a new encoding window ( bit 15 to 0); the previously transmitted data were relative to 3 encoding windows: the beginning of the current encoding window (of number SBN = i) is at a set of data of size equal to 4 MSS (bit 12 to 1) of the current packet (bit 15). In this example, there were two parity packets 750 transmitted for this SBN number (bits 30 and 28 to 1); • the beginning of the previous encoding window (SBN number = i-1) is at a set of data equal to 12 MSS (bit 4 to 1) of the current packet (bit 15), and covered a data set of size equal to 9 MSS. There has been only one parity packet 750 transmitted for this SBN number; • It is not known when the SBN = i-2 encoding window has started, but we know that the parity packet 750 which is at 16 MSS of the current packet, relates to it (bit 16 to 1). . In another embodiment, the PCL field is not present in the encapsulation area 752 but rather in the header of each TCP segment as a TCP option. This has the advantage of avoiding the receiver to synchronize on a beginning of packet 750 to obtain this PCL field. In such an embodiment, the steps 910 and 930 described hereinafter with reference to FIGS. 9C and 9B are optional. Note that the location mode presented with a granularity of MSS bytes is sufficient at the receiver block 102 to detect the presence of parity data in retransmission requests from the TCP layer 210 of the receiver block 420. transmitter 410 choose more finely the data it will actually retransmit because it has a fine knowledge of the location of parity data in the continuous stream TCP. In one embodiment (not shown), the transmitter block 410 transmits on the network fine location information of the parity data in the TCP stream, for example, as a TCP sequence number list. FIG. 8 illustrates an example of a storage table 800 managed by the flow scheduler 425. The storage table 800 of the flow scheduler 425 is intended to receive information on the packets received via the UDP carrier 100B. In this table, the scheduler 425 indicates for each expected packet, the expiry date of this packet, that is to say the date from which an undelivered packet becomes useless. Following the reception of UDP packets, and after analysis of the RTP protocol (UDP encapsulated passenger pack protocol in our example), or thanks to a control frame exchange between the transmitter block 410 and the receiver block 420, the scheduler 425 initializes the table 800 by pre-filling a number NbG of data packet encoding windows (this number can be set by the user, or be a number proportional to the RTT). Since the number of UDP packets of an encoding window is known, the scheduler creates, for each of the NbG blocks, as many lines as there are packets per encoding window. The expiry date of each package, being pre-filled. To determine the expiry date of a UDP frame T 1, the maximum time interval between two UDP frame transmissions over the LAN (frames received via the interface port 411) is obtained. Obtaining this maximum time interval may consist of analyzing the content of the RTP frames for establishing the flow. This maximum time interval can also be provided by a network administrator. Next, the maximum time interval obtained is multiplied by the number of frames separating the last retransmitted UDP frame T2 and the UDP frame Ti (this number is obtained by calculating the difference between the sequence numbers of the frames T1 and T2 ). In the example illustrated in FIG. 8, the storage table 800 comprises four columns: a column 801 indicating the sequence number of the UDP frame (SN field of the frame 720); a column 802 indicating the corresponding encoding window SBN number; a column 803 indicating whether the packet has been received or not. This column 803 is set to "No" by default. This column 803 is filled by the de-packager 421 at each UDP packet reception; a column 804 containing the expiry date pre-filled by the scheduler 425. This expiry date is for example specified with a granularity of one millisecond). FIG. 9A represents a flowchart of an algorithm for transmitting a data stream according to a particular embodiment of the method according to the invention, implemented by the transmitter block 410. On reception of a stream 401, the block transmitter 410 performs the following steps. In a step 920, the encoding module 415 generates M parity packets from the K packets of the stream 401 (the M parity packets are then also called encoded data). This gives a total number N of packets, such as N = M + K, to be transmitted via the tunnel 100. The decision module 412 hands, in a step 921, the M parity packets to the TCP 100A carrier via the packager 414 and, in a step 922, the K packets from the stream 401 to the UDP carrier 100B via the packager 413. Thus, the transmission of the packets of the stream via the UDP carrier 100B of the tunnel is made reliable by the transmission of parity packets via the TCP 100A carrier of the tunnel.

FIG. 9B shows a particular embodiment of an algorithm implemented within the marking module 416 (included in the transmitter block 410). When transmitting a current packet on the TCP 100A carrier, the marking module 416 performs the following steps.

Step 930 consists in determining, during the TCP stream, a frame start 750. In other words, at this step 930, it is sought to locate the header of a frame 750. To do this, a counter TCP sequence number (with the start value of the TCP connection as initialization) can be used because the size of the segments 750 is known (for example, the embedded protocol header 353 indicates the size of each frame). Note that in the case where the PCL field is not present in the encapsulation area 752 but is embedded in the TCP header via a TCP option, then the search for the frame header 750 is greatly simplified. Once the header is located, the "F" flag of the encapsulation area 752 is analyzed (step 931) to determine the nature of the contents of the current packet.

Then, the content of the PCL field 760 of the frame 750 is updated, by shifting to the left all the 16 bits indicating the location of the parity data (bits numbered 16 to 31 in FIG. 7), then allocating the current value of the flag "F" at the first bit (bit numbered 31 in FIG. 7). FIG. 9C shows a particular embodiment of an algorithm implemented within the TCP filter 4261 (included in the receiver block 420). Upon receiving a packet containing data from the interface port 411, and destined for the TCP layer 210, the TCP filter 4261 performs the following steps. Step 910 is to determine during the TCP stream a frame start 750.

In other words, in this step 910 we seek to locate the header of a frame 750. To do this, it is possible to use a TCP sequence number counter, as described above (step 930). Then, recovery and analysis of the PCL field are performed (step 911). The analysis of the PCL field makes it possible to know the location of the parity data 750 and especially of the SBN window number changes during the TCP stream.

Then, this TCP sequence number information supporting parity data and SBN window number change is listed in the index table 4264 (step 912).

Claims (13)

REVENDICATIONS1. A method of management by a receiving device (102) of a data stream transmitted by a transmitting device (101) via a communication link (100), the data of the data stream being transmitted to the receiving device by use of a protocol transport device without data acknowledgment, characterized in that the receiving device performs steps of: - detecting (620, 630) a loss of data relating to a packet of parity data not received by the receiving device, parity data transmitted by the transmitting device by using a transport protocol with acknowledgment and retransmission of data, the parity data having been generated from source data of said flow; checking (640, 650, 660) whether it is necessary for the transmitting device to retransmit said parity data packet not received, as a function of at least one criterion applied to the source data of said stream used to generate the parity data of said package not received; if it is not necessary for the transmitting device to retransmit said parity data packet not received, to cancel transmission to the transmitting device of a non-reception indication message by the receiving device of the data packet parity not received. 2. Method according to claim 1, characterized in that said step of verifying whether it is necessary for the transmitting device to retransmit said packet of non-received parity data comprises the steps of: detecting that the source data of said stream used to generate the parity data of said non-received packet have all been received by the receiving device; - decide that it is not necessary for the transmitting device to retransmit said parity data packet not received. The method of any one of claims 1 and 2, characterized in that said step of verifying whether it is necessary for the transmitting device to retransmit said parity data packet not received comprises the steps of: - determining ( 650) a time at which a given datum, among the source data of said stream used to generate the parity data of said non-received packet, must be obtained by the receiving device; detecting that the instant at which the determined data must be obtained by the receiving device exceeds an estimated time of reception of a retransmission of the parity data packet not received; - decide that it is not necessary for the transmitting device to retransmit said parity data packet not received. 4. Method according to claim 3, characterized in that the estimated time of reception is determined from a round trip time of the data transmitted according to the transport protocol with acknowledgment and retransmission of data. The method according to any one of claims 1 to 4, characterized in that said step of verifying whether it is necessary for the transmitting device to retransmit said parity data packet not received comprises the steps of: detecting that the number of parity data (s) already received by the receiving device makes it possible to reconstitute the source data of said stream used to generate the parity data of said packet not received; - decide that it is not necessary for the transmitting device to retransmit said parity data packet not received. The method according to any one of claims 1 to 5, characterized in that the receiving device first performs a step of intercepting (610) said non-receiving indication message of the parity data packet not received, and in that the step of canceling transmission to the transmitting device of a non-receiving indication message comprises steps of: - deleting said intercepted non-receiving indication message; generating (670) a stuffing packet that overrides the parity data packet not received; transmitting the generated stuffing packet to an acknowledgment processing module so as to obtain a receive indication message of said non-received parity data packet. The method of claim 6, characterized in that the stuffing packet has an identifier and size identical to those of said parity data packet not received. 8. Method according to any one of claims 1 to 7, characterized in that, if it is necessary for the transmitting device to retransmit said parity data packet not received, the receiving device performs a step of transmitting (690) said non-receiving indication message of the parity data packet not received to the transmitting device. 9. Method according to any one of claims 1 to 8, characterized in that the communication link is a communication tunnel interconnecting local area networks, and each of the transmitter and receiver devices is a tunnel head belonging to a respective local area network. , and in that the source data is generated by a source terminal device of a said local area network and is intended for a destination terminal device of a said separate local area network. Method according to any of claims 1 to 9, characterized in that a predefined size encoding window is applied to the source data used to generate the parity data of said non-received packet, and in that each data parity of said non-received packet has the same identifier as a predetermined position source data in the encoding window. 11. Computer program product, characterized in that it comprises program code instructions for implementing the method according to at least one of claims 1 to 10, when said program is executed on a computer. A computer readable storage medium storing a computer program comprising a set of computer executable instructions for carrying out the method according to at least one of claims 1 to 10. Receiving device (102) comprising means for managing a data stream transmitted by a transmitting device (101) via a communication link (100), the data of the data stream being transmitted to the receiving device by use of a protocol transport device without data acknowledgment, characterized in that the receiver device comprises: means for detecting a loss of data relating to a packet of parity data not received by the receiver device, parity data having been transmitted by the transmitting device using a transport protocol with acknowledgment and retransmission of data, the parity data having been generated from source data of said stream; means for verifying whether it is necessary for the transmitting device to retransmit said parity data packet not received, as a function of at least one criterion applied to the source data of said stream used to generate the parity data of said non-received packet; means for canceling transmission to the transmitting device of a non-reception indication message by the receiving device of the parity data packet not received, said means for canceling being activated if the means for verifying detect that it is not necessary for the transmitting device to retransmit said parity data packet not received. 15