Trusted Tester: P2p Auto-Updating of Chromebooks
Adam Naor
Hi Folks -
I was asked by our product team to see if any ANZ schools have a need/desire to do a trusted tester of a new auto-updating scheme for ChromeOS. You can read through this and let me know if this is applicable to your school and if you want to test this out.
Thanks!
Adam
Peer-to-peer (P2P) auto-update is a way for Chrome devices to update from nearby devices instead of downloading the update from Google’s servers or an intermediate caching proxy, if you have one set up. This feature can significantly reduce the Internet bandwidth needed to update Chrome devices, and it can update your Chrome devices more quickly if you have higher bandwidth available on your local network.
Requirements
Peer-to-peer connectivity must be allowed (E.g., client isolation must be disabled)
Multicast / mDNS must not be filtered or blocked on the LAN.
Devices must be running Chrome OS version 31 or higher.
Devices must be enterprise enrolled.
P2P will only work between devices of the same make and model.
If all of these requirements are not met, this P2P feature won’t work, but devices can still receive updates from Google.
How does it work?
Devices enabled for P2P will act as both a P2P server and a P2P client in the following manner:
Devices will continue to request update information from Google’s servers via HTTPS.
When an update is available, the requesting device (the P2P client) will query its local network (LAN) using mDNS to determine if any other devices are acting as a P2P server for the update . If no P2P server is found, the device will not use P2P and will download the update from Google as usual (utilizing any intermediate caching proxies, if applicable).
In addition to advertising that it has update files, a P2P server also advertises how many P2P clients are currently downloading from it. This enables P2P clients to pick the P2P server with the least load.
P2P clients will not initiate a download if the number of connections on the LAN is greater than the number you specify (the default is 3). If there are more devices connected to the LAN, the device will wait for the update. If a device doesn’t complete the update via P2P within five days, future updates will be done through Google or an intermediate caching proxy, if you have that set up.
As soon as the client starts downloading the update, it starts acting as a P2P server for that update. By not having to wait for the update to be completely downloaded, most clients on the network will download via P2P instead of downloading from Google.
See this video for a simulation of how a P2P update works.
Your update configuration settings such as pinning Chrome to a specific release channel will remain in effect. However, when applying via this mechanism the Randomly scatter setting is ignored.
Considerations for this setting
Your local network may see increased usage, but we limit the data transfer speed so this doesn’t have a big impact on your network traffic. P2P servers will not serve the update at a bandwidth higher than 125 kB/s. Consequently, the maximum LAN bandwidth used for updates via P2P is limited to 6 MBit/s (3 connections times 125 kB/s per connection, up and down). This helps avoid saturating the LAN.
The devices acting as servers will see increased background task usage and use more battery. The limit on active P2P downloads will reduce the impact of this on any single device.
Sign Up for this Trusted Tester
To sign up for the Trusted Tester to have the P2P updates enabled for your domain, fill out the Sign Up Form.
Get Started with P2P Auto-Update
After you sign up, we will email you a confirmation when we enable the feature for your domain. Once it's enabled, follow these steps:
Sign in to your Admin console at https://admin.google.com.
Navigate to Device Management > Chrome > Device Settings to set policies for Chrome devices in your domain.
Enable the P2P Auto-Update checkbox.