Cool, that makes sense on multiple levels. First, it reduces the patch size by not including non-consensus, client app specific, far-future networking changes.
Second, it highlights that how the blocks are communicated is not a part of consensus, and how the scheduled block size increases can add additional value by acting to spur innovation in this area.
It may be important for people to realize and internalize that second point. In addition to being another reason for people to accept this patch, it may help them expand their creativity to think beyond limitations that the current P2P protocol over the Internet may (eventually) have.
The scheduled nature of the increases gives network participants the opportunity to evaluate their situation and judge whether further evolution is needed on their part.
If adjustment is necessary, then such innovations can take many forms including things you already mentioned at
https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2, or even using other protocols over networks other than the Internet (e.g.- via Sneakernet, a future bitcoin satellite link, an Andreas Antonopoulos guerilla style "short wave radio hooked to a fence" [
https://youtu.be/3mUcpsbnhGE?t=14m20s] transmission, or more likely a mesh network in developing or otherwise constrained locations, etc...). Basically, if the medium is constraining the message, then changing the medium can be a solution.
Nice, I think I prefer your latest sigop counting correction over the initial easy tran size limit too. That adds value for people willing to switch. I noticed block 365955 took my 2.2GHz machine almost 5 minutes to validate the other day. I was wondering if that showed up during your last 100,000 block high sigop count analysis? It's always possible it was something else, but I've got a decent SSD and wasn't doing anything much else at the time when I saw that.