I'm just guessing here but there might be a couple of reasons.
- RTMFP protocol maintains a connection in case it needs to reestablish a connection (e.g. switching network interface from wired to wifi networks)
- RTMFP requires a connection to handle group connections and also when new peers join the network the "host" needs to be connected to start the P2P rendevous
- Adobe wants to control the usage of their P2P technology (Cirrus is beta and not to be used for commercial products so maybe they're using it as a "backdoor" to manage that access)
the traffic you're seeing between you and Cirrus is just keepalive pings, which keep any NAT/firewall translations/holes open and fresh. this mechanism can also signal your application if (for whatever reason) your connection to the server is abruptly lost. the keepalive mechanism is also leveraged to help Cirrus notice any IP address change your client might have (example: switching from wireless to wired) in a timely manner.
your connection to the server must be kept up in order to make the semantics of the API and networking model make sense. your peerID is only reachable with help from your server. the NetConnection is where your RTMFP endpoint lives, and NetStreams and NetGroups operate over/within it. closing the NetConnection destroys the network endpoint, so any resources using it must also be destroyed. additionally, exactly the same thing happens if you close an RTMP NetConnection; we decided that maintaining consistency would make the most sense to developers.