This is great -- this will be a nice complement and bring Radia into the P2P space, which is definitely needed given the volume of software updates today. One question - how will the peers be defined, so that peers aren't pulling from other peers located at a different site or network segment. We want peers pulling from other peers when they are "close". Will it be based on local subnet segment?

We'd also like to see it as soon as possible for software management, and not have to wait too long after Patch Management and OSMan.

This should be software first, patch and OS.

Nigel, agree. Would like to see Software first.

I'm thinking that probably 100% of the customer base is managing software through Radia, the same cannot be said for patches and operating systems, therefore software should always be the priority. In this instance I can see how the size of the new patch updates has driven this development but software should be either first or very quickly afterwards.

Cheers

I would also agree that Software should be the first to benefit from the new P2P functionality but Patch is a very close second. There are Radia customers who are seeing much less traffic from Patch management due to the isolation of the security only kb for deployment via a custom bulletin which does not require the wsusscn2.cab file to be updated. This significantly decreases the amount of Patch traffic to end points over previous months by eliminating the need to update/deploy the wsusscn2.cab file each month. There are also a few Radia customers who have expanded the Patch Management role to take over some Software deployment increasing the Patch traffic while decreasing Software traffic.

My view of the P2P is that the first agent per site (non-laptop or configurable) goes and gets the resources for a new service after checking that nobody else has it (ideally while stopping others from doing the same) and then hosts the resources and the others get and host the resources from that machine, everything everywhere (configurable). This gets rid of Streamline Satellites completely as they all become proxies and share. If you have to sync to the Satellite then that's defeated the object of P2P and there's little difference to the existing solution.

Would be great to have P2P support for both Software & Patch delivery in the next release followed by OS. Reducing the number of Satellites should definitely be a consideration as Nigel pointed out.

Can we also gather some thoughts on Windows 7, 8, 10 patch rollup deployments as well as Windows 10 upgrades as these items have put massive burden on the network in many organizations due

to their size. How many of us are doing Windows 10 upgrades (or planning to) in the field using Radia and how's it going?

Gowhar, we use WSUS in our environment (not Patch) -- and Win10 has certainly increased the bandwidth consumption from server to server when syncing out the patches, and also server to client, when clients call in for updates. Especially the Feature Upgrade, which is around 3.5 GB if you run it from the ISO. WSUS manages to reduce this to around 2 GB -- but having 1000s of clients download a 2GB file is not ideal. We don't really like the "Windows as a Service" approach -- seems geared more for consumers than the enterprise. One possibility is using Microsoft's Branch Cache (P2P mode) for these Feature Upgrades -- I believe that is supposed to work although we haven't verified it.

Our customer is using Radia for all 3, SW, Patch, and OS Manager.  We are planning on using SW Mgr for Windows 10 OS branch feature upgrades, and we are using Patch Mgr for the rollup patches.  So, we are interested in seeing this feature in all products, not just one or the other.  We have 320,000 workstations and 5,000 servers we are servicing, so this is a very needed feature.  Since we have so many Radia servers, I am also interested in seeing this being available in v9.1.

Sincerely appreciate the comments and feedback points from you all.

As far as working of P2P is concerned, the first client does not get the full resource but a partial chunk of p2p data. Many other clients get such smaller chunks from the P2P server and host them for others to pickup. Each client will then go and fetch different chunks from other peers and will assemble them locally to get the full resource.

On sync-up, currently our model will collocate P2P server software in a satellite. Each P2P server will sync with Core from time to time and update itself with any resources published recently.This will ensure that each P2P server is able to serve a site locally efficiently and the admin is able to visibly see the benefits of P2P. Though we can plan a deployment with one global P2P server serving across geographies, the peers will have to get their content from others present in other cities & subnets (over WAN) and it could defy the purpose of P2P and might increase the time taken for content distribution, increase the WAN traffic etc and could end up being much slower than traditional content distribution.

We too initially considered software management to be the first one to adopt P2P. Given that Patching is an inescapable monthly task where at least 200+MB of data is
transferred to thousands of endpoints, we decided to go ahead with the Patch Module first. We'll ensure that we include Software and OS Management modules subsequently.

Sorry, I am late to this topic.  I am failing to see much value if it works the way you describe.  If we already have a server on the LAN, P2P is a much lower priority for us.  To be of much use, the P2P would need to behave more like the MS implementation in Win10 where the client can identify that other clients on the LAN have chunks and get them from those clients first. Increasingly, ALL the servers are in the cloud and there will be NO local satellites.

So 

Throttle communication to the P2P servers (in the cloud) so as not to affect the WAN connection.

Throttle downloading processes from the cloud, so as to not affect the WAN connection.

Have the client be able to figure out who locally has a chunk and not go further afield unless there is no local chunk available. I would think this would be the primary function of the P2P solution. (organizing who has what where and how to get this information.)

Hi John,

Thanks for the comment. 

  We’re implementing P2P in the same traditional way like you’ve mentioned. If P2P is enabled in Radia, then a Radia P2P server module will be co-located at a satellite (streamlined) server which is closest to the endpoints. The first few chunks will be downloaded by endpoints from the P2P server and subsequently, the peers in the same LAN will serve each other with their chunks of data. This will reduce load on the server, avoid large downloads from server to each endpoint and ensure faster distribution of data to each endpoint.   If a satellite is on a LAN and serves x number of subnets/endpoints, we suggest that P2P server is placed on the same satellite or LAN so that the same endpoints are served by this new P2P server in the LAN and traffic is contained among the peers in the same LAN.

   Our solution will not stop the admins from configuring a P2P server at the top of Satellite hierarchy so that peers get their data from other peers across WAN, but we don’t advise it.

   If Bandwidth throttling is enabled in Radia, we would ensure that P2P also honors the throttling. P2P honoring Bandwidth throttling might not come in the first release but certainly in the subsequent releases.

   Hope this helps and please let me know if you have any additional questions.

Hi, Any update on this?

Hi Tony,

 We're getting 10.0 CP1 ready for GA, slated for release in Calendar quarter - 1Q2018.

 A few customers have come forward to try the dev-preview 10.0 CP1 build with P2P capabilities.

 Please let me know if any of you would be interested too.

Yes, we'd like to test and understand how to implement.