WO2019174779A1

WO2019174779A1 - Local cache sharing via a peer-to-peer connection

Info

Publication number: WO2019174779A1
Application number: PCT/EP2018/085971
Authority: WO
Inventors: Adam Bergkvist; Zaheduzzaman SARKER; Daniel BERGSTRÖM; Daniel Lindström
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-03-15
Filing date: 2018-12-19
Publication date: 2019-09-19

Abstract

A retrieving client device (12B) transmits a request (18B) for a resource (16) to a server (14), via a secure end-to-end connection (20B) with the server (14) or a gateway associated with the server (14). The retrieving client device (12B) receives from the server (14), via the secure end-to-end connection (20B), a response to the request (18B) indicating a client-cache device (12A) that is a client device which has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A). The retrieving client device (12B) may then retrieve the at least a portion (16A) of the resource (16) from the client-cache device (12A) via a peer-to-peer connection between the retrieving client device (12B) and the client-cache device (12A).

Description

LOCAL CACHE SHARING VIA A PEER-TO-PEER CONNECTION

BACKGROUND

Content distribution networks (CDNs) improve content delivery by moving content to servers that are closer to client devices and thereby offloading the delivery responsibility of the content origin. This improves latency and reduces bottlenecking at the origin.

Complexities arise, though, when the content is to be delivered via a secure end-to-end connection between the client device and the origin, such as using Hyper Text Transfer Protocol Secure (HTTPS). The secure nature of the connection jeopardizes the ability of servers to cache the content closer to the client devices. Moreover, even if content can be cached at caches closer to the client devices despite secure connections, the content may nonetheless be evicted at those caches as the content ages and/or reduces in popularity.

SUMMARY

Some embodiments exploit a peer-to-peer connection between client devices for a client device to share at least a portion of a resource from its local cache with one or more other client devices. Some embodiments advantageously do so in a way that still supports client devices communicating with a server (that is the origin of the resource) using a secure end-to-end connection and/or that still enables client devices to retrieve a resource even if caches have evicted the resource, e.g., due to content aging or decreased popularity. For example, some embodiments extend an out-of-band caching protocol to allow clients to directly retrieve resource portion(s) from other clients.

More particularly, embodiments herein include a method performed by a retrieving client device for retrieving a resource. The method comprises transmitting a request for a resource to a server via a secure end-to-end connection with the server or a gateway associated with the server. The method may further include receiving from the server, via the secure end-to-end connection, a response to the request indicating a client-cache device that is a client device which has at least a portion of the resource in a local cache of the client-cache device. The method may also include retrieving the at least a portion of the resource from the client-cache device via a peer-to-peer connection between the retrieving client device and the client-cache device.

In some embodiments, the method may also comprise choosing, from among multiple sources that the response indicates as being a source for the at least a portion of the resource, which one of the multiple sources to retrieve said at least a portion of the resource from, and wherein the retrieving is performed based on the choosing. Embodiments herein also include a method performed by a client-cache device configured with a local cache. The method may comprise transmitting a request for a resource to a server via a secure end-to-end connection with the server or a gateway associated with the server. The method may further include receiving a response to the request from the server via the secure end-to-end connection, wherein the response includes the resource. The method may also comprise storing at least a portion of the resource in a local cache of the client-cache device. The method may further include transmitting the at least a portion of the resource, as stored in the local cache, from the client-cache device to a retrieving client device via a peer-to- peer connection established between the retrieving client device and the client-cache device.

In some embodiments, the method may also comprise transmitting to the server information indicating that the client-cache device stores at least a portion of the resource in the local cache.

In either of the methods performed by the retrieving device or the client-cache device, the retrieving client device and the client-cache device in some embodiments are included in a group of client devices that are connectable via a peer-to-peer connection. In this case, the method may further comprise transmitting to the server a token associated with the group of client devices. The token in some embodiments comprises a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong.

Embodiments further include a method performed by a server. The method may comprise receiving from a retrieving client device a request for a resource via a secure end-to- end connection between the retrieving client device and the server or between the retrieving client device and a gateway associated with the server. The method may also comprise transmitting to the retrieving client device a response to the request indicating a client-cache device that is a client device which has at least a portion of the resource in a local cache of the client-cache device.

In some embodiments, the method performed by the server also comprises, before receiving the request, receiving from the client-cache device information indicating that the client-cache device stores the at least a portion of the resource in the local cache.

Alternatively or additionally, the method performed by the server may further comprise, before receiving the request, receiving from the client-cache device a token associated with the group of client devices and information indicating that the client-cache device stores the at least a portion of the resource in the local cache. In this case, the method may further comprise receiving from the retrieving client device the same token along with the request, and, based on receiving the same token from the retrieving client device as the token received from the client- cache device, determining to indicate to the retrieving client device that the client-cache device has at least a portion of the resource in a local cache of the client-cache device. The token in some embodiments comprises a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong.

In any of the above embodiments, the response from the server may include a resource map that maps the at least a portion of the resource to the client-cache device or a prefetch link relation that links the at least a portion of the resource to the client-cache device. Alternatively or additionally, the response may include header fields and an out-of-band content encoding that directs the retrieving client device to one or more other client devices, including the client-cache device, for retrieval of the at least a portion of the resource.

Also in any of the above embodiments, the retrieving client device and the client-cache device may be included in a group of client devices that are connectable via a peer-to-peer connection. In this case, the group of client devices may comprise client devices that belong to the same local subnet, that belong to the same private Internet Protocol (IP) address subnet, and/or that are on the same local network and have the same gateway that connects the local network to a wide area network.

Embodiments also include corresponding apparatus, computer programs, and carriers (e.g., computer readable mediums). For example, embodiments include a retrieving client device for retrieving a resource. The retrieving client device is configured (e.g., via

communication circuitry and processing circuitry) to transmit a request for a resource to a server via a secure end-to-end connection with the server or a gateway associated with the server. The retrieving client device may further be configured to receive from the server, via the secure end- to-end connection, a response to the request indicating a client-cache device that is a client device which has at least a portion of the resource in a local cache of the client-cache device. The retrieving client device may also be configured to retrieve the at least a portion of the resource from the client-cache device via a peer-to-peer connection between the retrieving client device and the client-cache device.

Embodiments also include a client-cache device configured with a local cache. The client-cache device may be configured (e.g., via communication circuitry and processing circuitry) to transmit a request for a resource to a server via a secure end-to-end connection with the server or a gateway associated with the server. The client-cache device may further be configured to receive a response to the request from the server via the secure end-to-end connection, wherein the response includes the resource. The client-cache device may also be configured to store at least a portion of the resource in a local cache of the client-cache device. The client-cache device may further be configured to transmit the at least a portion of the resource, as stored in the local cache, from the client-cache device to a retrieving client device via a peer-to-peer connection established between the retrieving client device and the client- cache device.

Embodiments moreover include a server. The server may be configured (e.g., via communication circuitry and processing circuitry) to receive from a retrieving client device a request for a resource via a secure end-to-end connection between the retrieving client device and the server or between the retrieving client device and a gateway associated with the server. The server may also be configured to transmit to the retrieving client device a response to the request indicating a client-cache device that is a client device which has at least a portion of the resource in a local cache of the client-cache device.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a communication system that includes client devices and a server according to some embodiments.

Figure 2 is a logic flow diagram of a method performed by a retrieving device for retrieving a resource according to some embodiments.

Figure 3 is a logic flow diagram of a method performed by a client-cache device configured with a local cache according to some embodiments.

Figure 4 is a logic flow diagram of a method performed by a server according to some embodiments.

Figure 5A is a call flow diagram of an example for a client to retrieve a resource from a peer client according to some embodiments.

Figures 5B-5C show an example JSON encoding of a resource map with support for a peer-to-peer sub-resource according to some embodiments.

Figure 6A is a block diagram of a client-cache device according to some embodiments.

Figure 6B is a block diagram of a client-cache device according to other embodiments.

Figure 7A is a block diagram of a retrieving client device according to some

embodiments.

Figure 7B is a block diagram of a retrieving client device according to other

embodiments.

Figure 8A is a block diagram of a server according to some embodiments.

Figure 8B is a block diagram of a server according to other embodiments. DETAILED DESCRIPTION

Figure 1 shows a communication system 10 according to some embodiments. The system 10 as shown includes client devices 12A and 12B, as well as a server 14 that is the origin for a resource 16. The server 14 may for instance be a web server and the resource 16 may be a web resource (e.g. , a web page). The client device 12A transmits a request 18A for the resource 16 to the server 14 via a secure end-to-end connection 20A, e.g., an HTTPS connection (HTTP over Transport Layer Security, TLS) or other secure connection that protects the privacy and/or integrity of the resource 16. The secure connection 20A may be between the client device 12A and the server 14 itself, or between the client device 12A and a gateway 14A associated with the server 14. The gateway 14A may for instance connect the server 14 to one or more data networks 22, e.g., including the Internet or other (public) wide area network(s). Regardless, the server 14 transmits to the client device 12A a response 24A to the request 18. The response 24A as shown includes the resource 16.

The client device 12A stores at least a portion 16A of the resource 16 in a local cache 26 of the client device 12A, i.e., the local cache 26 is local to the client device 12A. The local cache 26 may store for instance one or more portions of the resource 16 (e.g., also referred to as sub- resources), or store the resource 16 in full. Where the resource 16 is a webpage, for example, the local cache 26 may store one or more portions of the webpage content (e.g., one or more images) as sub-resources. With the at least a portion 16A of the resource 16 stored in its local cache 26, client device 12A may be referred to herein as a client-cache device 12A.

The client-cache device 12A notably shares its local cache 26 with one or more other client devices that similarly request the resource 16 or the at least a portion 16A of the resource 16. The server 14 in this regard may coordinate or otherwise assist other client devices with discovering or identifying availability of resource portion(s) 16A in the local cache 26 at the client-cache device 12A. The server 14 may do so, for instance, based on receiving signaling from the client-cache device 12A indicating that the client-cache device 12A has the resource portion(s) 16A stored in its local cache 26 and/or that the client-cache device 12A is willing to share its local cache 26 with other client devices.

More particularly, client device 12B itself transmits a request 18B for the resource 16 to the server 14 (or a different server not shown) via a secure end-to-end connection 20B e.g., an HTTPS connection. Again, the secure connection 20B may be between the client device 12B and the server 14 itself, or between the client device 12B and the gateway 14A associated with the server 14. Although Figure 1 show that the request 16B is for the same resource 16 as requested by client device 12A, in other embodiments the request 16B may be for a different resource (not shown) than the resource 16 requested by client device 12A, but that different resource has one or more portions or sub-resources in common with the resource 16 requested by client device 12A. Regardless, the server 14 transmits to the client device 12B a response 24B to the request 18B.

Rather than the response 24B including the requested resource 16 (in full), though, the response 24B indicates the client-cache device 12A as having at least a portion 16A of the resource 16 in the local cache 26 of the client-cache device 12A. That is, the response 24B effectively directs client device 12B to the client-cache device 12A for retrieval of the at least a portion 16A of the resource 16. In some embodiments, for example as shown, the response 24B in this regard includes a so-called resource map 28. The resource map 28 may map the at least a portion 16A of the resource 16 to the client-cache device 12A. In embodiments where the response 24B exploits an out-of-band caching protocol (e.g., as described elsewhere herein), for instance, the response 24B may include header fields and an out-of-band content encoding that directs the retrieving client device 12B to one or more other client devices, including the client-cache device 12A, for retrieval of the at least a portion 16A of the resource 16. The header fields in some embodiments convey one or more keys for decrypting the out-of-band content, i.e. , the at least a portion 16A of the resource 16 which may be encrypted over the secure connection 20A. That is, in this case, the server 14 in its response 24B provides one or more decryption keys to the retrieving client device 12B as well as information directing the device 12B to the client-cache device 12A for retrieving the actual resource portion(s) 16A which may be decrypted using the one or more decryption keys.

Accordingly, based on the response 24B, the client device 12B may choose to retrieve the at least a portion 16A of the resource 16 from the client-cache device 12A. The client device 12B in this regard may be referred to herein as a retrieving client device 12B. Correspondingly, the client-cache device 12A transmits the at least a portion 16A of the resource 16, as stored in the local cache 26, to the retrieving client device 12B. In some embodiments, the client-cache device 12A may do so in response to receiving a request 33 from the retrieving client device 12B for such at least a portion 16A of the resource 16.

Notably, according to some embodiments, the client-cache device 12A transmits and the retrieving client device 12B retrieves the at least a portion 16A of the resource 16 via a peer-to- peer (P2P) connection 30 established (directly) between the devices 12A, 12B. In some embodiments, then, the retrieving client device 12B retrieves the at least a portion 16A of the resource 16 directly from the client-cache device 12A. The response 24B from the server 14 to the retrieving client device 12B may assist in setup of the peer-to-peer connection 30, such as by providing an IP address and/or port at the client-cache device 12A to which the retrieving client device 12B may connect. The response 24B may alternatively or additionally indicate a protocol (e.g., websocket) via which the retrieving client device 12B may communicate with the client-cache device 12A.

Some embodiments thereby exploit a peer-to-peer connection 30 for a client device to share resource portion(s) 16A from its local cache 26 with one or more other client devices. Some embodiments advantageously do so in a way that still supports client devices

communicating with the server 14 using a secure end-to-end connection. For example, some embodiments extend an out-of-band caching protocol to allow clients to directly retrieve resource portion(s) 16A from other clients.

Some embodiments are advantageous in that they provide less load on origin servers 14 and top-level caches, by resolving requests closer to the requesting client, and/or provide less load on caches and CDNs when there are clients nearby which can be accessed (via P2P) at a low cost. Additionally or alternatively, some embodiments provide increased robustness via data replication, shorter load times for clients, and/or increased origin server capacity (e.g., a server may serve a large number of clients with the same amount of resources). Also, some embodiments enable retrieval of a resource from a nearby peer that still has that resource long after nearby caches have evicted the resource, e.g., as may be the case for a patch or update whose popularity has decreased since its release. Furthermore, some embodiments support a secure web environment and are suitable for dealing with surges in demand (e.g., many clients from the same geographical region visiting news outlets in the case of a large news event). Moreover, some embodiments provide these features in a fashion that is transparent to users or system administrators.

In some embodiments, the retrieving client device 12B and the client-cache device 12A are included in a group (or domain) of client devices that are connectable via a peer-to-peer connection. For example, the group of client devices may comprise client devices that belong to the same (local) subnet, e.g., the same private Internet Protocol (IP) address subnet.

Alternatively or additionally, the group of client devices may comprise client devices that are on the same (local) network and have the same gateway 34 (shown in Figure 1 ) that connects the (local) network to a wide area network, e.g., DN(s) 22. In this case, the server 14 may be external to the local network.

In embodiments where the devices 12A, 12B are included in such a group, the client- cache device 12A may transmit to the server 14 (e.g., in or in associated with request 18A) a token 34A associated with the group of client devices. The token may be for instance a subset token associated with the subnet (where the group corresponds to the subnet). The token 34A in some embodiments comprises a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong. Similarly, the retrieving client device 12B may also transmit to the server 14 (e.g., in or in associated with request 18B) a token 34B associated with the group of client devices. These tokens may be the same in some embodiments, or may otherwise correspond to and be decipherable as associated with the group of client devices. In some embodiments, then, based on receiving the token 34A, 34B from the devices 12A, 12B, the server 14 may determine to indicate to the retrieving client device 12B that the client-cache device 12A has at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A.

In these and other embodiments, though, the client devices in the group may be able to connect to each other without involving network address translation (NAT) or firewall traversal (e.g., interactive connectivity establishment, ICE). In other embodiments, though, the client devices 12A, 12B may be wireless devices or user equipment that are behind multiple or different carrier graded NATs, e.g., such that physically proximate client devices may not necessarily belong to the same subnet. In this case, discovery of peer information for establishing the peer-to-peer connection 30 may require communicating outside of the subset (within the same or different mobile operators).

Figure 2 shows a method 100 performed by a retrieving client device 12B for retrieving a resource 16 according to some embodiments. The method 100 includes transmitting a request 18B for a resource 16 to a server 14 via a secure end-to-end connection 20B with the server 14 or a gateway 14A associated with the server 14 (Block 110). The method 100 further includes receiving from the server 14, via the secure end-to-end connection 20B, a response 24B to the request 18B indicating a client-cache device 12A that is a client device which has at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A (Block 120). The method 100 also includes retrieving the at least a portion 16A of the resource 16 from the client-cache device 12A via a peer-to-peer connection 30 between the retrieving client device 12B and the client-cache device 12A (Block 130). In some embodiments, the method 100 may further includes establishing the peer-to-peer connection 30 between the retrieving client device 12B and the client-cache device 12A (Block 125).

In some embodiments, the retrieving client device 12B and the client-cache device 12A are included in a group of client devices that are connectable via a peer-to-peer connection. In this case, the group of client devices may comprise client devices that belong to the same local subnet. Alternatively or additionally, the group of client devices may comprise client devices that belong to the same private Internet Protocol (IP) address subnet. Alternatively or additionally, the group of client devices may comprise client devices that are on the same local network and have the same gateway that connects the local network to a wide area network. In this latter case, the server 14 may be external to the local network.

In any of the above embodiments for method 200, the server 14 may be a web server and the resource 16 may be a web resource.

In any of the above embodiments for method 200, the method 200 may further comprise transmitting to the server 14 a token 34B associated with the group of client devices. In this case, the token 34B in some embodiments is a subnet token and the group is a subnet to which the client devices in the group belong. Alternatively or additionally, the token 34B in some embodiments comprises a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong. Alternatively or additionally, the token 34B in some embodiments is included in or transmitted in association with the request 18B for the resource 16.

In any of the above embodiments for method 200, the response 24B in some embodiments includes a resource map 28 that maps the at least a portion 16A of the resource 16 to the client-cache device 12A or a prefetch link relation that links the at least a portion 16A of the resource 16 to the client-cache device 12A.

In any of the above embodiments for method 200, the response 24B in some embodiments includes header fields and an out-of-band content encoding that directs the retrieving client device 12B to one or more other client devices, including the client-cache device 12A, for retrieval of the at least a portion 16A of the resource 16.

In any of the above embodiments for method 200, the secure end-to-end connection 20B may be a Hypertext Transfer Protocol Secure (HTTPS) connection.

Figure 3 shows a corresponding method 200 performed by a client-cache device 12A configured with a local cache 26. The method as shown includes transmitting a request 18A for a resource 16 to a server 14 via a secure end-to-end connection 20A with the server 14 or a gateway 14A associated with the server 14 (Block 210). The method 200 further includes receiving a response 24A to the request 18A from the server 14 via the secure end-to-end connection 20A (Block 220). The response 24A includes the resource 16. The method 200 as shown also includes storing at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A (Block 230). Further, the method 200 includes transmitting the at least a portion 16A of the resource 16, as stored in the local cache 26, from the client-cache device 12A to a retrieving client device 12B via a peer-to-peer connection 30 established between the retrieving client device 12B and the client-cache device 12A (Block 240). In some embodiments, the method 200 may further includes establishing the peer-to-peer connection 30 between the retrieving client device 12B and the client-cache device 12A.

In some embodiments, the method 200 further comprises transmitting to the server 14 information indicating that the client-cache device 12A stores at least a portion 16A of the resource 16 in the local cache 26.

In any of the above embodiments for method 200, the method 200 may further comprise transmitting to the server 14 a token 34A associated with the group of client devices. In this case, the token 34A in some embodiments is a subnet token and the group is a subnet to which the client devices in the group belong. Alternatively or additionally, the token 34A may comprise a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong. Alternatively or additionally, the token 34A may be included in or transmitted in association with the request 18A for the resource 16 and/or in information transmitted to the server 14 indicating that the client-cache device 12A stores at least a portion 16A of the resource 16 in the local cache 26.

In any of the above embodiments for method 200, the secure end-to-end connection 20A may be a Hypertext Transfer Protocol Secure (HTTPS) connection.

Figure 4 shows a method 300 performed by the server 14 according to some

embodiments. The method 300 as shown includes receiving from a retrieving client device 12B a request 18B for a resource 16 via a secure end-to-end connection 20B between the retrieving client device 12B and the server 14 or between the retrieving client device 12B and a gateway 14A associated with the server 14 (Block 310). The method 300 also includes transmitting to the retrieving client device 12B a response 24B to the request 18B indicating a client-cache device 12A that is a client device which has at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A (Block 320).

In some embodiments, the method 300 further comprises, before receiving the request 18B, receiving from the client-cache device 12A information indicating that the client-cache device 12A stores the at least a portion 16A of the resource 16 in the local cache 26.

In any of the above embodiments for method 300, the server 14 may be a web server and the resource 16 may be a web resource.

In any of the above embodiments for method 300, the method further comprise, before receiving the request 18B, receiving from the client-cache device 12A a token 34A associated with the group of client devices and information indicating that the client-cache device 12A stores the at least a portion 16A of the resource 16 in the local cache 26. In this case, the method may also comprise receiving from the retrieving client device 12B the same token 34B along with the request 18B, and based on receiving the same token 34B from the retrieving client device 12B as the token 34A received from the client-cache device 12A, determining to indicate to the retrieving client device 12B that the client-cache device 12A has at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A. In some

embodiments, the token 34B is a subnet token and the group is a subnet to which the client devices in the group belong. Alternatively or additionally, the token 34B may comprise a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong.

In any of the above embodiments for method 300, the response 24B may include a resource map 28 that maps the at least a portion 16A of the resource 16 to the client-cache device 12A or a prefetch link relation that links the at least a portion 16A of the resource 16 to the client-cache device 12A.

In any of the above embodiments for method 300, the response 24B may include header fields and an out-of-band content encoding that directs the retrieving client device 12B to one or more other client devices, including the client-cache device 12A, for retrieval of the at least a portion 16A of the resource 16.

In any of the above embodiments for method 300, the secure end-to-end connection 20B may be a Hypertext Transfer Protocol Secure (HTTPS) connection.

Note that in embodiments now shown, the response 24B may include a prefetch link relation that links the at least a portion 16A of the resource 16 to the client-cache device 12A.

Note that although embodiments have been described as supporting secure end-to-end connections, some embodiments alternatively or additionally support nonsecure end-to-end connections (e.g., using HTTP instead of HTTPS).

In some embodiments, the server 14 sets a cache expiration timer for the client-cache device’s local cache so as to avoid indicating that resource portion(s) 16A are available at the client-cache device upon expiration of the cache expiration timer.

One or more other embodiments will now be described in a context where the client devices in the group belong to the same subnet.

Web sites are increasingly being consumed from mobile devices. Mobile devices typically experience varying connectivity characteristics due to load or varying signal/noise ratio on the radio link(s). Occasionally, the connectivity will be lost or so low the browsing experience is practically interrupted. Such situations can be predicted and, leveraging new capabilities, measures can be taken to avoid serious degradation of browsing experience.

The Web is moving to a HTTPS-only paradigm, making existing in-line caches obsolete as they cannot intercept traffic when end-to-end encryption is used. Indeed, as mentioned, caching for web resources is not possible when moving web content to an HTTPS-only paradigm. Some solutions to make caching a viable solution in an all HTTPS web scenario introduce a concept called“resource map”. The resource map improves the performance by allowing the origin to convey information about the location of many cached resources using one object (the resource map) to the client rather than having the client request every resource separately from the origin, only to be re-directed to the cache. In short, it saves a lot of client - origin round-trip times.

High-demand content is often available in several cache nodes. However, content that has seen a decrease in popularity may be removed to free cache storage. This may mean that a resource needs to be loaded from a cache far away or even from the origin even though another client on the same subnet has the resource.

Some embodiments herein exploit an out-of-band caching (OOBC) protocol. The OOBC protocol is relevant for shared caching for HTTPS. More particularly, shared caches allow an HTTP server to offload the responsibility for delivering certain content. Content in the shared cache can be accessed efficiently by multiple clients, saving the origin server from having to serve those requests and ensuring that clients receive responses to cached requests more quickly. Proxy caching is the most common configuration for shared caching. A proxy cache is either explicitly configured by a client, discovered as a result of being automatically configured, or interposed automatically by an on-path network entity (this latter case being called a transparent proxy). HTTPS [RFC2818] prevents the use of proxies by creating an authenticated end-to-end connection to the origin server or its gateway that is authenticated. This provides a critical protection against man-in-the-middle attacks, but it also prevents the proxy from acting as a shared cache.

Some approaches allow for conditionally delegating the hosting of secure content to the same server. This delegation allows a client to send a request for an "https" resource via a proxy rather than insisting on an end-to-end TLS connection. This enables shared caching for a limited set of "https" resources, as selected by the server. A secure content delegation mechanism is used to create a separate resource that contains encrypted and integrity protected content. See Ericsson, G., Holmberg, C., and M. Thomson, "An Architecture for Secure Content Delegation using HTTP", February 2016. A client that signals a willingness to support this feature can be provided a response with an out-of-band encoding that identifies this resource. The client can then make a request for that content to a proxy cache rather than directly to the origin server.

Also, an architecture is described for content distribution via third-party content distribution networks with reduced privileges. This architecture allows an origin server to delegate the responsibility for delivery of the payload of an HTTP response to a third party.

That party is unable to modify this content. The content is encrypted, which in some cases will prevent the third party from learning about the content.

The distribution of content on the web at scale is necessarily highly distributed. Large amounts of content need large numbers of servers. And distributing those servers closer to clients has a significant, positive impact on performance. This has led to large networks of content distribution servers, in some cases operated by web sites, but often run by third parties in service to sites that don't have the resources to operate a network at very large scales. A content distribution network (CDN) aims to dramatically improve the performance of content delivery by moving content closer to clients and by offloading the delivery responsibility to servers that are highly optimized for that task. A major drawback of existing solutions for content distribution is that an origin is required to yield control over their content to the CDN. A CDN is able to see and modify content that they distribute. In some cases, expediency dictates that the CDN be given control over the entire origin.

Secure content delegation describes how an origin server might securely delegate the responsibility for serving content to a CDN. The solution comprises three basic components: (i) A delegation component allows an origin server to delegate specific resources to another server; (ii) Integrity attributes ensure that the content cannot be modified by the delegated server; and (iii) Confidentiality protection limits the ability of the delegated server to learn what the content holds.

The out-of-band content encoding provides the basis for delegation of content distribution. A request is made to the origin server, but in place of the complete response only response header fields and an out-of-band content encoding is provided. The out-of-band content encoding directs the client to retrieve content from another resource. The content encoding specifically preserves header fields sent by the origin server, rejecting any

unauthenticated header fields that might be provided by the CDN.

Learning about header fields and out-of-band cache locations for resources in advance of needing to make requests to those resources allows a client to avoid making requests to the origin server. This can greatly improve the performance of applications that make multiple requests of the same server, such as web browsing or video streaming. Without defining any new additional protocol mechanisms, HTTP/2 server push [RFC7540] can be used to provide requests, responses and the out-of-band content encoding information describing resources. Since no actual content is included, this requires relatively little data to describe a number of resources. Once this information is available, the client no longer needs to contact the origin server to acquire the described resources.

Some embodiments herein extend the out-of-band caching (OOBC) protocol with functionality to allow clients to directly load content from other clients.

According to some embodiments, clients can host part of online resources during a limited time after the client itself has accessed the resource. Other clients can experience shorter response times when consuming online resources. Servers can serve the same contents fewer times, and hence serve a larger number of clients with the same amount of resources. Some embodiments provide these and other features in a fashion totally transparent to the users or administrators of the system. Some advantages of embodiments herein may include: (i) Less load on origins and top level caches when requests can be resolved close to the client; (ii) Less load on caches and CDNs when there are clients nearby which can be accessed at a lower cost; (iii) More robustness via data replication; (iv) Shorter load times for clients; (v) Retains the ability from the OOBC protocol to provide caching in a secure Web environment; and/or (vi) Suitable technology to deal with surges in demand, e.g., many clients from the same geographical region visiting news outlets in the case of a large news event.

Figure 5A shows an example according to some embodiments. In Figure 5A, Client 1 fetches a resource from an origin using out-of-band caching. More particularly, Client 1 requests the resource from the origin along with a subnet token. A subnet token in some embodiments is a hash of several pieces of information, such as gateway IP address, that describes the network that a client resides on. The token itself should not reveal any information, but two clients with the same subnet token are (very likely) able to communicate with each other directly peer-to- peer. As this is the first request from that subnet, the token is not used.

In response to the request, the origin composes a resource. The origin may optionally mark certain sub resources as suitable for peer-to-peer (p2p) access. A resource map is then delivered to client 1. Client 1 then downloads some of the sub resources.

As shown, Client 1 selects a set of resources that it finds suitable to share with other clients on the network. In the remainder of this example such resources are called p2p sub- resources. Client 1 may then send a request to the origin with meta data on shared resources. Client 1 may send this request along with its subnet token. The meta data includes connection protocol, endpoint information and the set of resources that are shared from this client.

Client 2 then fetches a resource from an origin using out-of-band caching. In this regard, Client 2 requests the resource from the origin along with its subnet token. The origin composes a resource map with sub resources that, in this example, contains one or more p2p resources that are available for Client 2’s subnet token. The p2p resource may have a favorable selection criteria, but the origin normally includes an extra source entry in the resource map in addition to the p2p resource. An example of how the JavaScript Object Notation (JSON) data of the resource map with P2P sub resource support may look like is included in Figures 5B-5C.

A new resource map is then delivered to Client 2. Client 2 downloads resources from the resource map based on the selection criteria. This may include setting up a peer-to-peer connection with Client 1. The OOB Caching implementation may use any suitable protocol to download the resource. For example, client-server protocols like HTTP(S) or WebSockets. If the peer-to-peer connection fails, it may fall back and try a different location for the resource. Note that in some embodiments a mechanism ensures data integrity when resources are loaded from a second peer. Note also that a cache may re-populate its storage by loading a resource from a client.

Note further that embodiments herein may use any of one or more communication protocols known in the art or that may be developed, such as IEEE 802. xx, Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), Global System for Mobile

telecommunications (GSM), Long Term Evolution (LTE), WiMax, New Radio (NR), or the like. Accordingly, although sometimes described herein in the context of 5G, the principles and concepts discussed herein are applicable to 4G systems and others.

A client device as used herein is any type device capable of communicating with another client device or a server. A client device in some embodiments is a user equipment. A user equipment may refer to a wireless device, a mobile station, a laptop, a smartphone, a machine- to-machine (M2M) device, a machine-type communications (MTC) device, a narrowband Internet of Things (loT) device, etc. That said, it should be noted that the user equipment does not necessarily have a“user” in the sense of an individual person owning and/or operating the user equipment. A user equipment may also be referred to as a wireless communication device, a radio device, a radio communication device, a wireless terminal, or simply a terminal - unless the context indicates otherwise, the use of any of these terms is intended to include device-to- device UEs or devices, machine-type devices or devices capable of machine-to-machine communication, sensors equipped with a wireless device, wireless-enabled table computers, mobile terminals, smart phones, laptop-embedded equipped (LEE), laptop-mounted equipment (LME), USB dongles, wireless customer-premises equipment (CPE), etc. In the discussion herein, the terms machine-to-machine (M2M) device, machine-type communication (MTC) device, wireless sensor, and sensor may also be used. It should be understood that these devices may be UEs, but may be generally configured to transmit and/or receive data without direct human interaction.

In an IOT scenario, a user equipment as described herein may be, or may be comprised in, a machine or device that performs monitoring or measurements, and transmits the results of such monitoring measurements to another device or a network. Particular examples of such machines are power meters, industrial machinery, or home or personal appliances, e.g.

refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a user equipment as described herein may be comprised in a vehicle and may perform monitoring and/or reporting of the vehicle’s operational status or other functions associated with the vehicle. The client-cache device 12A herein may perform the processing herein by implementing any functional means or units. In one embodiment, for example, the client-cache device 12A comprises respective circuits configured to perform the steps shown in Figure 2. The circuits in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more microprocessors, carries out the techniques described herein. That is, in some embodiments memory of the client-cache device 12A contains instructions executable by the processing circuitry whereby the client-cache device 12A is configured to carry out the processing herein.

Figure 6A illustrates additional details of a client-cache device 12A in accordance with one or more embodiments. As shown, the client-cache device 12A includes processing circuitry 40 and communication circuitry 42. The communication circuitry 42 is configured to

communicate with other equipment in the system 10 (e.g., retrieving client device 12B via peer- to-peer communication and/or server 14). The processing circuitry 40 is configured to perform processing described above, e.g., in Figure 2, such as by executing instructions stored in memory 44. The processing circuitry 40 in this regard may implement certain functional means or units.

Figure 6B in this regard illustrates additional details of client-cache device 12A in accordance with one or more other embodiments. As shown, the client-cache device 12A may include a transmitting unit or module 46 for transmitting a request 18A for a resource 16 to a server 14 via a secure end-to-end connection 20A with the server 14 or a gateway 14A associated with the server 14. Further included is a receiving unit or module 48 for receiving a response 24A to the request 18A from the server 14 via the secure end-to-end connection 20A. The response 24A includes the resource 16. Also included is a storing unit or module 49 for storing at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A. The transmitting unit or module 46 is also for transmitting the at least a portion 16A of the resource 16, as stored in the local cache 26, from the client-cache device 12A to a retrieving client device 12B via a peer-to-peer connection 30 established between the retrieving client device 12A and the client-cache device 12B.

The retrieving client device 12B herein may perform the processing herein by implementing any functional means or units. In one embodiment, for example, the retrieving client device 12B comprises respective circuits configured to perform the steps shown in Figure 3. The circuits in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more microprocessors, carries out the techniques described herein. That is, in some embodiments memory of the retrieving client device 12B contains instructions executable by the processing circuitry whereby the retrieving client device 12B is configured to carry out the processing herein.

Figure 7A illustrates additional details of retrieving client device 12B in accordance with one or more embodiments. As shown, the retrieving client device 12B includes processing circuitry 50 and communication circuitry 52. The communication circuitry 52 is configured to communicate with other equipment in the system 10 (e.g., client-cache device 12A and/or server 14). The processing circuitry 50 is configured to perform processing described above, e.g., in Figure 3, such as by executing instructions stored in memory 54. The processing circuitry 50 in this regard may implement certain functional means or units.

Figure 7B in this regard illustrates additional details of retrieving client device 12B in accordance with one or more other embodiments. As shown, the retrieving client device 12B may include a transmitting unit or module 56 for transmitting a request 18B for a resource 16 to a server 14 via a secure end-to-end connection 20B with the server 14 or a gateway 14A associated with the server 14. Further included may be a receiving unit or module 58 for receiving from the server 14, via the secure end-to-end connection 20B, a response 24B to the request 18B indicating a client-cache device 12A that is a client device which has at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A. Also included is a retrieving unit or module 59 for retrieving the at least a portion 16A of the resource 16 from the client-cache device 12A via a peer-to-peer connection 30 between the retrieving client device 12B and the client-cache device 12A.

The server 14 herein may perform the processing herein by implementing any functional means or units. In one embodiment, for example, the server 14 comprises respective circuits configured to perform the steps shown in Figure 4. The circuits in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more

microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more microprocessors, carries out the techniques described herein. That is, in some embodiments memory of the server 14 contains instructions executable by the processing circuitry whereby the server 14 is configured to carry out the processing herein.

Figure 8A illustrates additional details of server 14 in accordance with one or more embodiments. As shown, the server 14 includes processing circuitry 60 and communication circuitry 62. The communication circuitry 62 is configured to communicate with other equipment in the system 10 (e.g., client-cache device 12A and/or retrieving client device 12B). The processing circuitry 60 is configured to perform processing described above, e.g., in Figure 4, such as by executing instructions stored in memory 64. The processing circuitry 60 in this regard may implement certain functional means or units.

Figure 8B in this regard illustrates additional details of server 14 in accordance with one or more other embodiments. As shown, the server 14 may include a receiving unit or module 68 for receiving from a retrieving client device 12B a request 18B for a resource 16 via a secure end-to-end connection 20B between the retrieving client device 12B and the server 14 or between the retrieving client device 12B and a gateway 14A associated with the server 14. Also included is a transmitting unit or module 66 for transmitting to the retrieving client device 12B a response 24B to the request 18B indicating a client-cache device 12A that is a client device which has at least a portion 16A of the resource 16 in a local cache 26 of the client-cache device 12A.

Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs.

A computer program comprises instructions which, when executed on at least one processor (e.g., of client-cache device 12A, retrieving client device 12B, or server 14), cause the processor to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.

Claims

CLAIMS What is claimed is:

1. A method performed by a retrieving client device (12B) for retrieving a resource (16), the method comprising:

transmitting (1 10) a request (18B) for a resource (16) to a server (14), via a secure end- to-end connection (20B) with the server (14) or a gateway (14A) associated with the server (14);

receiving (120) from the server (14), via the secure end-to-end connection (20B), a

response (24B) to the request (18B) indicating a client-cache device (12A) that is a client device which has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A); and

retrieving (130) said at least a portion (16A) of the resource (16) from the client-cache device (12A) via a peer-to-peer connection (30) between the retrieving client device (12B) and the client-cache device (12A).

2. The method of claim 1 , further comprising choosing, from among multiple sources that the response indicates as being a source for said at least a portion (16A) of the resource (16), which one of the multiple sources to retrieve said at least a portion (16A) of the resource (16) from, and wherein said retrieving is performed based on said choosing.

3. A method performed by a client-cache device (12A) configured with a local cache (26), the method comprising:

transmitting (210) a request (18A) for a resource (16) to a server (14), via a secure end- to-end connection (20A) with the server (14) or a gateway (14A) associated with the server (14);

receiving (220) a response (24A) to the request (18A) from the server (14) via the secure end-to-end connection (20A), wherein the response (24A) includes the resource (16);

storing (230) at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A); and

transmitting (240) the at least a portion (16A) of the resource (16), as stored in the local cache (26), from the client-cache device (12A) to a retrieving client device (12B) via a peer-to-peer connection (30) established between the retrieving client device (12B) and the client-cache device (12A).

4. The method of claim 3, further comprising transmitting to the server (14) information indicating that the client-cache device (12A) stores at least a portion (16A) of the resource (16) in the local cache (26).

5. The method of any of claims claim 1-4, wherein the retrieving client device (12B) and the client-cache device (12A) are included in a group of client devices that are connectable via a peer-to-peer connection (30), and wherein the method further comprises transmitting to the server (14) a token associated with the group of client devices.

6. A method performed by a server (14), the method comprising:

receiving (310) from a retrieving client device (12B) a request (18B) for a resource (16) via a secure end-to-end connection (20B) between the retrieving client device (12B) and the server (14) or between the retrieving client device (12B) and a gateway associated with the server (14); and

transmitting (320) to the retrieving client device (12B) a response to the request (18B) indicating a client-cache device (12A) that is a client device which has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A).

7. The method of claim 6, further comprising, before receiving the request (18B), receiving from the client-cache device (12A) information indicating that the client-cache device (12A) stores the at least a portion (16A) of the resource (16) in the local cache (26).

8. The method of any of claims 6-7, further comprising:

before receiving the request (18B), receiving from the client-cache device (12A) a token associated with the group of client devices and information indicating that the client-cache device (12A) stores the at least a portion (16A) of the resource (16) in the local cache (26);

receiving from the retrieving client device (12B) the same token along with the request (18B); and

based on receiving the same token from the retrieving client device (12B) as the token received from the client-cache device (12A), determining to indicate to the retrieving client device (12B) that the client-cache device (12A) has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A).

9. The method of any of claims 1 -2 and 5-8, wherein the response includes a resource map that maps the at least a portion (16A) of the resource (16) to the client-cache device (12A) or a prefetch link relation that links the at least a portion (16A) of the resource (16) to the client- cache device (12A).

10. The method of any of claims 1 -2 and 5-9, wherein the response includes header fields and an out-of-band content encoding that directs the retrieving client device (12B) to one or more other client devices, including the client-cache device (12A), for retrieval of the at least a portion (16A) of the resource (16).

1 1 . The method of any of claims 1 -10, wherein the retrieving client device (12B) and the client-cache device (12A) are included in a group of client devices that are connectable via a peer-to-peer connection, and wherein the group of client devices comprises client devices that belong to the same local subnet, that belong to the same private Internet Protocol (IP) address subnet, and/or that are on the same local network and have the same gateway that connects the local network to a wide area network.

12. The method of any of claims 5 and 8, wherein the token comprises a hash of information associated with the group of client devices and/or the subnetwork to which the client devices in the group belong.

13. A retrieving client device (12B) for retrieving a resource (16), the retrieving client device (12B) configured to:

transmit a request (18B) for a resource (16) to a server (14) via a secure end-to-end connection (20B) with the server (14) or a gateway associated with the server (14);

receive from the server (14), via the secure end-to-end connection (20B), a response to the request (18B) indicating a client-cache device (12A) that is a client device which has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A); and retrieve said at least a portion (16A) of the resource (16) from the client-cache device (12A) via a peer-to-peer connection between the retrieving client device (12B) and the client-cache device (12A).

14. The retrieving client device of claim 13, configured to perform the method of any of claims 2, 5, and 9-12.

15. A client-cache device (12A) configured with a local cache (26), the client-cache device

(12A) configured to:

transmit a request (18A) for a resource (16) to a server (14) via a secure end-to-end connection (20A) with the server (14) or a gateway associated with the server (14);

receive a response (24A) to the request (18A) from the server (14) via the secure end- to-end connection (20A), wherein the response (24A) includes the resource (16); store at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A); and

transmit the at least a portion (16A) of the resource (16), as stored in the local cache (26), from the client-cache device (12A) to a retrieving client device (12B) via a peer-to-peer connection established with the retrieving client device (12B).

16. The client-cache device of claim 15, configured to perform the method of any of claims

4-5 and 9-12.

17. A server (14) configured to:

receive from a retrieving client device (12B) a request (18B) for a resource (16) via a secure end-to-end connection (20B) between the retrieving client device (12B) and the server (14) or between the retrieving client device (12B) and a gateway associated with the server (14); and

transmit to the retrieving client device (12B) a response to the request (18B) indicating a client-cache device (12A) that is a client device which has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A).

18. The server of claim 17, configured to perform the method of any of claims 6-12.

19. A retrieving client device (12B) for retrieving a resource (16), the retrieving client device (12B) comprising:

communication circuitry; and

processing circuitry configured to:

transmit a request (18B) for a resource (16) to a server (14) via a secure end-to- end connection (20B) with the server (14) or a gateway associated with the server (14);

receive from the server (14), via the secure end-to-end connection (20B), a

response to the request (18B) indicating a client-cache device (12A) that is a client device which has at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A); and

retrieve said at least a portion (16A) of the resource (16) from the client-cache device (12A) via a peer-to-peer connection between the retrieving client device (12B) and the client-cache device (12A).

20. The retrieving client device of claim 19, configured to perform the method of any of claims 2, 5, and 9-12.

21 . A client-cache device (12A) configured with a local cache (26), the client-cache device (12A) comprising:

communication circuitry; and

processing circuitry configured to:

transmit a request (18A) for a resource (16) to a server (14) via a secure end-to- end connection (20A) with the server (14) or a gateway associated with the server (14);

receive a response (24A) to the request (18A) from the server (14) via the secure end-to-end connection, wherein the response (18A) includes the resource (16);

store at least a portion (16A) of the resource (16) in a local cache (26) of the client-cache device (12A); and

transmit the at least a portion (16A) of the resource (16), as stored in the local cache (26), from the client-cache device (12A) to a retrieving client device (12B) via a peer-to-peer connection (30) established with the retrieving client device (12B).

22. The client-cache device of claim 21 , configured to perform the method of any of claims 4-5 and 9-12.

23. A server (14) comprising:

communication circuitry; and

processing circuitry configured to:

24. The server of claim 23, configured to perform the method of any of claims 6-12.

25. A computer program comprising instructions which, when executed on at least one processor of a retrieving client device (12B), cause the at least one processor to carry out the method according to any of claims 1-2, 5, and 9-12.

26. A computer program comprising instructions which, when executed on at least one processor of a client-cache device (12A), cause the at least one processor to carry out the method according to any of claims 3-5 and 9-12.

27. A computer program comprising instructions which, when executed on at least one processor of a server (14), cause the at least one processor to carry out the method according to any of claims 5-12.

28. A carrier containing the computer program of any of claims 25-27, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.