As far as I know, the workflow is like this.. (assuming that the master/agent communication has already happened at least once and the correct certs are inplace and approved)
Client -> master - Client communicates with master, ready to start a run, requests 'pluginsync'
Master -> client - Master sends client the appropriate collection of plugins for plugin sync (native types/providers, custom facter facts, etc).
Client gathers results from facter
Client -> Master - Client sends results from facter fact gathering to master
Master - Complies catalog for client based on facts from the client, and puppet code in the appropriate environment
Master -> Client - Sends complied catalog to client
Client - Scans system, comes up with list of what the state of resources from the catalog are currently, and uses info from the catalog to know what they should be.
Client - starts process of transforming the state that needs to be changed from 'is' to 'should be', this is the actual application of the catalog on the client.
Client (from master), - during the run, any file resources (puppet:///) are pulled from the master to the client at the time the resource is being evaluated.
Client records output of catalog application, gathered up into the run report.
Client -> Master - Sends result of the puppet application, as a .yml report
This doesn't specifically answer what part of the client/master interaction is represented by each of your peaks, but I hope it helps you understand the back and forth communication between the master and client.