Method of QUIC communication via multiple paths

Abstract

A method of communication, in which a communicating device is situated behind a residential gateway able to implement the QUIC (Quick UDP Internet Connection) protocol and connected to a plurality of paths Pi, where i=1, . . . , N, on which the gateway can dispatch data packets received from the communicating device, and receive packets of data intended for the communicating device. The method includes: the gateway associating a respective connection identifier C_ID #i with each of the paths Pi; and, when the gateway receives a data packet from the communicating device, the gateway transmits this data packet on one of the paths Pi while taking into account the connection identifier C_ID #i corresponding to this path Pi.

Claims

1. A communication method comprising the following acts: a) a residential gateway associating a respective connection identifier C_ID #i with each one of a plurality of paths Pi, wherein the residential gateway is capable of implementing the QUIC (Quick UDP Internet Connection) protocol and is connected to the plurality of paths Pi, in which i=1, . . . , N, over which said residential gateway can send data packets received from a communicating device situated behind the residential gateway, and receive data packets intended for the communicating device; and b) in response to the residential gateway receiving a data packet from the communicating device, the residential gateway transmitting this data packet over one of the paths Pi by taking account of the connection identifier C_ID #i associated with this path Pi.

2. The communication method as claimed in claim 1, wherein the method comprises, beforehand, the following acts: said communicating device discovers said plurality of paths Pi, and the communicating device sends to said residential gateway one or more messages specifying a respective connection identifier C_ID #i for each of said respective paths Pi, and wherein, in response to the residential gateway receiving a data packet from the communicating device comprising a connection identifier C_ID #i, the residential gateway transmits this data packet over the path Pi associated with this connection identifier C_ID #i.

3. The communication method as claimed in claim 2, wherein said residential gateway sends to said communicating device a message containing list of the paths Pi known to the residential gateway.

4. The communication method as claimed in claim 1, wherein, in response to said residential gateway receiving from said communicating device a data packet comprising a connection identifier C_ID #0, the residential gateway transmits this data packet over one of said paths Pi, by replacing said connection identifier C_ID #0 with said connection identifier C_ID #i associated with this path Pi if these connection identifiers C_ID #0 and C_ID #i are different from one another.

5. The communication method as claimed in claim 4, wherein, in response to said data packet received from said communicating device being transmitted in response to a message transmitted by its correspondent, said residential gateway transmits this data packet to the correspondent on the path on which said message arrived at the residential gateway.

6. The communication method as claimed in claim 1, wherein at least one of said communicating device or said residential gateway sends to the correspondent of the communicating device a message comprising a list of the paths known to the at least one of the communicating device or the residential gateway.

7. The communication method as claimed in claim 1, wherein said residential gateway implements a traffic distribution policy comprising traffic distribution rules between the different available networks.

8. The communication method as claimed in claim 7, wherein said residential gateway sends to the communicating device a message describing the traffic distribution policy to be observed.

9. A communicating device comprising: a processor; and a non-transitory computer-readable medium comprising instructions stored thereon which when executed by the processor configure the communicating device to perform acts comprising: discovering a plurality of paths Pi connected to a residential gateway capable of implementing the QUIC (Quick UDP Internet Connection) protocol, in which i=1, . . . , N, over which said residential gateway can send data packets received from said communicating device, which is situated behind the residential gateway, and receive data packets intended for said communicating device, and sending to said residential gateway one or mom messages specifying a respective connection identifier C_ID #i for each of said respective paths Pi.

10. The communicating device as claimed in claim 9, wherein the communicating device is further configured to receive from said residential gateway, and take account of, a message containing the paths Pi known to the residential gateway.

11. A residential gateway comprising a processor; and a non-transitory computer-readable medium comprising instructions stored thereon which when executed by the processor configure the residential gateway to implement the QUIC (Quick UDP Internet Connection) protocol and to perform acts comprising: associating a respective connection identifier C_ID #i with each of a plurality of paths Pi connected to the residential gateway, in which i=1, . . . , N, and over which said residential gateway can send data packets received from a communicating device situated behind said residential gateway, and receive data packets intended for said communicating device, and in response to the residential gateway receiving a data packet from the communicating device, transmitting this data packet over one of the paths Pi by taking account of the connection identifier C_ID #i associated with this path Pi.

12. The residential gateway as claimed in claim 11, wherein the residential gateway is further configured to: receive from said communicating device one or more messages specifying a respective connection identifier C_ID #i for each said respective paths Pi, and in response to receiving a data packet from the communicating device comprising a connection identifier C_ID #i, transmit this data packet over the path Pi associated with this connection identifier C_ID #i.

13. The residential gateway as claimed in claim 11, wherein the residential gateway is further configured to: receive from said communicating device a data packet comprising a connection identifier C_ID #0, and transmit this data packet over one of said paths Pi, by replacing said connection identifier C_ID #0 by said connection identifier C_ID #i associated with this path Pi if these connection identifiers C_ID #0 and C_ID #i are different from one another.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Other aspects and advantages of the invention will become apparent on reading the following detailed description of particular embodiments, given as nonlimiting examples. The description refers to the accompanying figures, in which:

(2) FIG. 1, mentioned above, schematically represents a conventional QUIC connection comprising several “streams” (channels),

(3) FIG. 2 represents a gateway connected to a plurality of paths and capable of associating a respective connection identifier with each of said paths,

(4) FIG. 3 schematically represents a procedure of discovery of multiple paths according to a first embodiment of the invention,

(5) FIG. 4 represents the sending by a terminal of three packets within one and the same QUIC connection according to an example of said first embodiment,

(6) FIG. 5 represents a QUIC communication between a client C and a server S according to a second embodiment of the invention,

(7) FIG. 6 represents an example of format for a frame CID_UPDATE used for updating the QUIC connection identifier,

(8) FIG. 7 represents, according to a variant of said updating procedure, the replacement of the identifier of a QUIC connection between a client C and a server S,

(9) FIG. 8 represents an example of format for a frame MP_POLICY used to notify a traffic distribution policy to a correspondent,

(10) FIG. 9 represents a QUIC communication between a client T1 and a server S, according to a first variant of use of the frame MP_POLICY,

(11) FIG. 10 represents a QUIC communication between a client T1 and a server S, according to a second variant of use of the frame MP_POLICY, and

(12) FIG. 11 represents a multiple-path QUIC communication assisted by the network.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

(13) A number of embodiments of the invention will now be described.

(14) In these embodiments, a residential gateway is considered which is denoted CPE (initials for “Customer Premises Equipment”) connected to one or more networks N1, N2, N3, and so on, by one or more paths P1, P2, P3, and so on. As represented schematically in FIG. 2, the CPE associates a connection identifier C_ID #1 with a path linking it to the network N1, a connection identifier C_ID #2 with a path linking it to the network N2, a connection identifier C_ID #3 with a path linking it to the network N3, and so on. It will be noted that these connection identifiers are not necessarily all different from one another; in some cases, one and the same connection identifier may be used for all the packets sent or transmitted by the CPE over each of the paths in the context of one and the same QUIC communication.

(15) As illustrated in FIG. 2, the CPE can for example serve as intermediary in a QUIC communication between a server S and a terminal T1 (single interface, or multiple interfaces) located behind the CPE.

(16) According to a first embodiment, a terminal T1 is considered that is located behind a CPE and capable of implementing a multiple path discovery procedure. This discovery procedure is represented schematically in FIG. 3.

(17) To discover the multiple paths known to the CPE in addition to the paths that are locally visible, the terminal T1 can transmit messages, called DISCOVER_PATH( ); such a message can be sent over all or just some active network interfaces of the terminal.

(18) If multiple paths are known to the CPE, the latter sends a list of the available paths using the primitive ADVERT_PATHS(Pi). A given path Pi can be identified by:

(19) a path index local to the CPE (path identifier), for example, “1”, “2”, “155467”,

(20) an interface index local to the CPE (index interface), for example, “Ifindex1”, “Ifindex2”, “Ifindex15”,

(21) an interface name, for example “cellular”, “adsl”, “fiber”,

(22) an address or an external IP prefix, for example “1.2.3.4” or “2001:db8::/56”,

(23) a physical address, for example an MAC (Medium Access Control) address,

(24) a combination of an index and of an external IP address, or

(25) any other identifier, including any combination of the abovementioned information elements.

(26) The message ADVERT_PATHS(Pi) can be sent by a CPE following a solicitation from a terminal situated behind the CPE, or spontaneously, that is to say without the CPE having been explicitly solicited by a terminal. As an example, the CPE can send a message ADVERT_PATHS(Pi):

(27) on the restarting of the CPE,

(28) periodically over the local area network(s) to which different terminals are connected,

(29) when a new terminal connects to the CPE via the local area network,

(30) when the CPE connects to a new access network,

(31) when the CPE is disconnected from an access network inopportunely or not, or

(32) upon the changing of IP address/prefix allocated by an access network.

(33) When therefore a terminal T1 discovers a plurality of paths Pi, in which i=1, . . . , N, it determines a respective connection identifier C_ID #i for each respective path Pi. The terminal T1 then contacts the CPE to program packet distribution policies over the different available paths. To do this, the terminal T1 sends one or more messages MAP(C_ID #i, Pi). The message MAP( ) also, optionally, makes it possible to announce the characteristics of the traffic (notably, the IP addresses and the source and destination port numbers), in order to be able to identify a QUIC connection likely to route said traffic.

(34) It will be noted that the message MAP( ) can be sent before, or after, the setting up of a QUIC connection with a correspondent of the terminal T1.

(35) Following the reception of one or more message(s) MAP(C_ID #i, Pi), the CPE installs the associations as indicated by the terminal T1. If an association is already present for this terminal and for one and the same connection identifier, the CPE replaces it with a new instruction received from the terminal T1. The CPE uses a stable identifier, such as an MAC address, to identify the associations of one and the same terminal. The associations can have a limited lifetime.

(36) The CPE can complement the characteristic information of an association with information received from the correspondent of the terminal T1.

(37) The CPE can indicate to the terminal T1 another connection identifier to be used in case, for example, of conflict between an identifier C_ID #i and an identifier already chosen by another terminal. Other connection identifier selection policies can be executed by the CPE. The purpose of the allocation of the connection identifier by the CPE (or by a device installed by the operator) is to facilitate the identification of the QUIC connections. Indeed, the CPE anticipates the reception of QUIC packets by installing traffic profiles according to the connection identifier known previously. It will be noted in this respect that this possibility for an entity other than a client or a server of allocating a connection identifier is not known in the state of the art.

(38) Then, the CPE sends to the terminal T1 an acknowledgement message MAP_ACK( ) which provides an inventory of the installed associations. Optionally, the CPE can also return the other associations known for this terminal.

(39) In order to allow the CPE to distribute the traffic via the different multiple paths according to a policy known to the terminal T1, the latter must naturally use the appropriate identifier in accordance with the associations programmed previously on the CPE.

(40) It will be noted that the CPE can distribute the traffic received from a terminal between several paths available without said terminal having in any way communicated to the CPE traffic distribution instructions, nor even the terminal being informed of the existence of multiple paths. To this end, the CPE executes a traffic distribution algorithm according to the preconfigured policies.

(41) FIG. 4 illustrates, by way of example, the sending by a terminal T1 of three packets within one and the same QUIC connection; each of these packets is identified by a dedicated connection identifier C_ID #i. On reception of these packets by the CPE, the latter consults its associations table to determine the path to be used to send the packet to its destination. In this example, a packet whose connection identifier is C_ID #1 is transmitted via the network N1, a packet whose connection identifier is C_ID #2 is transmitted via the network N2, and a packet whose connection identifier is C_ID #3 is transmitted via the network N3. It will be noted that the packets transmitted are associated with the same connection identifier (denoted C_ID #a in FIG. 4); this identifier can be generated by the CPE, but also, as a variant, by the terminal T1 or by its correspondent.

(42) As mentioned above, the use of one and the same connection identifier C_ID on the various networks crossed allows the traceability of the QUIC connections when attaching to new networks, which threatens the confidentiality of the exchanges. Embodiments of the invention will now be described in which, to resolve this problem, “aliases” of QUIC connection identifiers can be created by one or other of the participants to a QUIC communication.

(43) Consider, for example, according to a second embodiment of the invention illustrated in FIG. 5, a client C located behind a CPE. This client C transmits data packets comprising a QUIC connection identifier denoted C_ID #0 generated by the client C.

(44) Following the reception of the first data packet characteristic of a new communication between the client C and the server S, the CPE puts in place associations between connection identifiers C_ID #i (aliases) and the respective paths Pi, for example by configuring an associations table in a database.

(45) It will be noted that an alias can be generated by the CPE, but also, as a variant, by the client C or by the server S. For example, if said first packet is received by the CPE from the server S over a path Pi, and this path comprises a connection identifier C_ID #i, the CPE preferably associates this alias C_ID #i with this path Pi.

(46) It will also be noted that various schemes are possible for the values assigned to the aliases with respect to the value of the “original” connection identifier C_ID #0, for example:

(47) C_ID #i identical to C_ID #0 regardless of i=1, . . . , N, or

(48) C_ID #i identical to C_ID #0 for a single value of i, or even

(49) C_ID #i different from C_ID #0 regardless of i=1, . . . , N.

(50) Moreover, any two aliases C_ID #i and C_ID #j, with i different from j, can have values that are the same or different from one another.

(51) The CPE then transmits said first packet to its recipient (server S or client C).

(52) Consequently, for each reception by the CPE of a packet characteristic of this communication from the client C, the CPE transmits this packet to the server S over one of the paths Pi, after consulting its associations table and modifying, in this packet (if necessary), the value of the QUIC connection identifier, that is to say replacing C_ID #0 with the alias C_ID #i associated with the path Pi (if C_ID #i is different from C_ID #0).

(53) The CPE can notably implement this procedure of rewriting the original QUIC connection identifier C_ID #0 in order to contribute to the preservation of the confidentiality of the data exchanged between the client C and the server S. During the communication, the CPE can decide to update the connection identifier if it connects to a new network, or if the data are distributed via multiple paths known to the CPE and/or to the server S. These aliases are then, preferably, known only to the CPE and to the server S.

(54) For a client or a server to be able to inform its correspondent of the migration of the QUIC connection identifier (C_ID), a procedure is proposed for migration of C_ID (for example during an active connection or upon a change of the attachment to the network), in which:

(55) the migration of C_ID can be initiated by the CPE, the client or the server;

(56) the migration of C_ID can take place at any moment during a QUIC connection; thus, the migration of C_ID can take place just before the migration of a connection to a new path (or a new network attachment), or take place just after the migration of a connection to a new path (or a new network attachment); and

(57) the same security keys are used to validate the migration of C_ID.

(58) To do this, the client or the server sends a frame of type “CID_UPDATE”. An example of format for this frame CID_UPDATE is represented in FIG. 6. This frame is sent in a QUIC message whose identifier is that of the QUIC connection already setup between the participants. This frame can be sent jointly with other data, or be sent in a dedicated QUIC message. On reception of the QUIC message which contains a frame CID_UPDATE by a correspondent, the latter proceeds with the conventional QUIC validations to ensure that the message originates from a legitimate terminal. Once the message is validated, the correspondent extracts the information contained in the frame CID_UPDATE.

(59) If the “event” field is set to “0” (MIGRATE), there is then an immediate updating of the connection identifier, as illustrated in FIG. 7 in which a connection identifier, denoted “OLD_CID” in this figure, is replaced by a new connection identifier, denoted “NEW_CID”. Any QUIC exchange under this connection must then use a new identifier.

(60) If the “event” field is set to “1” (ALIAS), an alias of the connection identifier C_ID #0 is then defined for each path. Several aliases can be indicated in one and the same frame.

(61) Whatever the embodiment, the operator may want to apply a traffic distribution policy. It will be assumed here that traffic distribution policies can be configured on the CPE, in order to allow it to distribute the traffic between the different networks available; these policies can be configured by a service provider or by a user; an example of policy consists in using the radio resources only in case of unavailability of a fixed access network or when the available resources (maximums) of the main access network (typically the wired network) no longer allow the traffic characteristic of a given application to be handled; the traffic distribution policies are critical, because an inappropriate use of the available resources can induce a rapid consumption of the quota available on a given access link, even provoke a significant increase in the billed amount to be paid by the user; the control of a traffic distribution policy is also critical for an operator because it makes it possible notably to minimize the risk of congestion of certain links (for example, the excessive use of a cellular connection by a multiple-interface CPE can cause a cell to be congested to the detriment of the single-interface mobile terminals). Advantageously, the CPE can adjust its traffic distribution policies according to the observed network conditions.

(62) The CPE can communicate to the terminal/client the traffic distribution policy to be observed, by means of the primitive MAP(C_ID #i, Pi, POLICY). The POLICY object can comprise, for example:

(63) a maximum volume of data to be sent per path,

(64) a traffic distribution ratio (for example, 10% for P1, 80% for P2, 10% for P3),

(65) an order of priority for invocation of the resources associated with each path (for example, use P1 first then P2 in case of congestion),

(66) a path which will be used only to backup a main path (for example, P2 is designated as backup path for P1),

(67) an indication according to which the path exhibiting the best RTT must be used,

(68) an indication according to which the paths exhibiting a similar RTT must be used,

(69) an indication according to which the “streams” with a high priority must be routed via given path.

(70) The terminal/client must observe the traffic distribution policy as indicated by the CPE. Given that the traffic distribution policy does not concern only the outgoing traffic but also the incoming traffic, a new frame, called MP_POLICY, is used to notify a correspondent of the terminal/client.

(71) A terminal/client capable of exchanging data via multiple paths can include a frame MP_POLICY in a QUIC message sent to its correspondent. This frame makes it possible to announce to the correspondent the list of the paths known to the terminal/client (notably, the addresses to be used to send data to the terminal/client without the latter having used one of these addresses previously to communicate with this correspondent), as well as, optionally, the incoming traffic distribution policy (from the correspondent to the terminal/client).

(72) A possible format for this frame MP_POLICY is represented in FIG. 8. In this figure:

(73) the “type” field indicates that it is an “MP_POLICY” frame,

(74) the “sub-type” field can indicate for example the following values:

(75) “0”: list of the multiple paths known to the transmitter; the “data” field must then include a list of paths known to the transmitter of the frame; as an example, the “data” field can include a list of IP addresses (or of ports) to be used to send packets to one and the same terminal under one and the same multiple-path connection;

(76) “1”: traffic distribution policy between the different multiple paths; the available paths can be used simultaneously;

(77) “2”: a maximum volume of data is to be sent per path; the “data” field specifies the volume and the path concerned;

(78) “3”: indicates a usage ratio per path; the “data” field specifies this policy, for example 10% for P1, 80% for P2, and 10% for P3;

(79) “4”: indicates that the best RTT algorithm must be used.

(80) The frame MP_POLICY can be sent by one of the participants, or by all the participants to a QUIC connection. It can be sent at any moment of a QUIC connection. It can be sent jointly with other control data or payload data. One or more frames MP_POLICY can be included in one and the same QUIC message. A frame MP_POLICY can be used to signal that a path is no longer available.

(81) A QUIC correspondent receiving a frame MP_POLICY saves a copy of the content of the frame in its QUIC connections table. Typically, this table contains connection identifiers (C_ID). If the frame mentions other IP addresses (or ports), the correspondent can use this information to communicate via multiple paths, that is to say send packets having as destination address (destination port) one of the addresses indicated in the frame MP_POLICY. Thus, the traffic distribution policies indicated in the frame MP_POLICY inform the correspondent of the approach to be followed to send the data of one and the same QUIC connection to the different available paths.

(82) FIG. 9 represents a QUIC communication between a terminal T1 and a server S, according to a first variant in which the terminal T1 announces to the server S the list of the paths available using a frame MP_POLICY. The frame is sent via the path which crosses the network N1. The server can send the data of this same connection via the other paths to the terminal T1 (N2 or N3) without the terminal T1 having used these paths to communicate with S.

(83) FIG. 10 represents a QUIC communication between a terminal T1 and a server S, according to a second variant in which a frame MP_POLICY is inserted by the CPE.

(84) According to a third variant (not represented), the content of the frame MP_POLICY can be controlled and possibly modified by the CPE. This variant makes it possible to add to the list of the multiple paths and to indicate the traffic distribution policy consistent with that of the operator, notably in the case where the CPE is operated by the operator. Thus, the CPE can remove the connection identifier from the public (that is to say unencrypted) header, if another connection identifier is included in the encrypted part of the QUIC message.

(85) Whatever the embodiment, in the case where the QUIC connection identifier used by a terminal is encrypted, a new identifier called “Provider Connection Identifier”, and denoted PC_ID, can be used by an operator to control the use of the different access networks accessible from a CPE to set up QUIC connections. Furthermore, as illustrated in FIG. 11, a device called “QUIC Provider Proxy” (denoted P in FIG. 11) is introduced into the network of the operator to control the routing of the data along the different multiple paths, but also to remove said identifier PC_ID before the routing of the data to their final destination.

(86) The “Provider Connection Identifier” information is:

(87) injected by a CPE or by a “QUIC Provider Proxy”,

(88) removed by the CPE before proceeding with the routing of the packets to the terminal, and

(89) removed by the QUIC Provider Proxy device before proceeding with the routing of the packets to the destination S.

(90) The frame MP_POLICY defined above can be used both by the CPE and by the “QUIC Provider Proxy” device to announce the different paths and the traffic distribution policy to be applied both for the uplink and for the downlink, according to the requirements.

(91) FIG. 11 shows how the “QUIC Provider Proxy” device (P) makes it possible to use the resources of the different multiple paths without effecting the QUIC connection identifier chosen by a terminal T1 located behind this CPE. The QUIC packets sent by T1 are intercepted by the CPE, which injects a unique identifier PC_ID #a and a frame MP_POLICY on the various available paths. On reception of these packets by a “QUIC Provider Proxy” device, this device saves the information contained in the frame MP_POLICY in the local connections table, then removes the objects PC_ID #a and MP_POLICY from the packets before sending them to their final destination.

(92) The invention can be implemented within communication network nodes, for example terminals, routers or residential gateways, by means of software and/or hardware components.

(93) The software components will be able to be incorporated in a conventional network node management computer program. That is why, as indicated above, the present invention relates also to a computer system. This computer system conventionally comprises a central processing unit controlling, by signals, a memory, and an input unit and an output unit. Furthermore, this computer system can be used to run a computer program comprising instructions for implementing any one of the communication methods according to the invention.

(94) Indeed, the invention also targets a computer program as described briefly above. This computer program can be stored on a medium that can be read by computer and can be executed by a microprocessor. This program can use any programming language, and take the form of source code, object code, or intermediate code between source code and object code, such as in a partially-compiled form, or in any other desirable form.

(95) The invention also targets an information medium that is non-removable, or partially or totally removable, comprising instructions of a computer program as described briefly above.

(96) This information medium can be any entity or device capable of storing the program. For example, the information medium can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic storage means, such as a hard disk, or even a USB key (“USB flash drive”).

(97) Also, the information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means. The computer program according to the invention can in particular be downloaded over a network of internet type.

(98) As a variant, the information medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of any one of the communication methods according to the invention.

(99) Although the present disclosure has been described with reference to one or more examples, workers skilled in the art will recognize that changes may be made in form and detail without departing from the scope of the disclosure and/or the appended claims.