In the context of the Internet, the ”big red button” problem can be stated as follows: given two Internet locations, improved QoS should either be guaranteed between them, or the connection which has ”pushed” the button should be terminated. QoS refers to various factors, such as bandwidth, latency, drop rate and jitter.
If the ”push” returns a successful response, higher QoS should be ensured on the route for the duration of the connection. Therefore, I believe that a design complying to the specifications would necessitate state being stored at the intermediate network nodes. If, as the internet was designed, with minimal state being stored on routers, priority (through which QoS could be ensured) should be given to packets solely based upon information contained in them. But in that case, because there would be nothing limiting the number of sources sending packets with high priorities through a router, it would be problematic to guarantee a minimum threshold for the QoS for the lifetime of a particular connection.
Therefore, it is my opinion that a solution for the given problem would entail ”reserving” a certain QoS on the desired path for the duration of a connection. Routers would have to store the reservation information related to the currently open connections (routers could periodically check which connections are still open). If a router cannot satisfy a QoS request, it should send a negative reply to the initiator, which would then close the connection. The IntServ architecture proposal  serves similar purposes. Reservations along a route could be made similarly to the proposed RSVP protocol .
However, this has several downsides: given the scale of today’s Internet, the amount of state that the routers would have to store may become large. Moreover, most of the routers in deployment today support ”best effort” service, thus requiring a massive undertaking in terms of physical resource upgrade if the service is to be widely deployed. It would also impose a restriction on the types of network equipment needed in order to fully utilize the internet: if a large enough number of users would use QoS guarantees, those that would not have this ability would most probably be left with low quality connections to the highly accessed nodes. Besides the technical issues, challenges of a different nature may also appear, such as preventing the abuse of such a mechanism should it become a general utility on the Internet.
Technically, the ”big red button” could be developed in my opinion. However, the availability of such a mechanism to users would violate several of the principles upon which the internet was built and which have made it widely adopted. It would require impractical changes in terms of physical equipment, and create a number of potential security issues. All this, in my opinion prevents it from being useful as an Internet-wide utility, while certainly being a possibility in more restricted settings.
 Integrated Services in the Internet Architecture: an Overview. http://tools.ietf.org/html/rfc1633.