[Not about NANOG per se]
re: host stacks. other improvements i've heard of that are relevant to "reacting to http" are (1) applying slow-start- and congestion-avoidance-type algorithms to the rate at which new tcp connections are opened and (2) having kernels share data in the protocol control blocks relevant to the tcp algorithms across connections to the same host (or even "network"). there are issues with both of these ideas, but the point is that we can do things to react to the observed behavior resulting from the extreme popularity of the web
Given that, roughly, TCP congestion avoidance algorithm `estimates' bandwidth available to a connection on a particular route, perhaps this estimate can be used as a bandwidth *hint* for any further traffic between the two hosts. That is, such an estimate should be useful beyond the connection that computed it. Why throw away hard earned statistical data if we can figure out how to reuse it? [Thinking aloud here...] Perhaps a part of the TCP congestion avoidance algorithm can be factored out in some sort of a `traffic central' module that tries to give you the best bandwidth/packet loss estimate it has for a given route provided you keep it updated with what you learn (i.e. TCP tells it when a packet is lost etc). A new TCP connection can then immediately start off with a bigger window (and won't open the window too wide too quickly). Multiple connections between two hosts can avoid what would be largely redundant estimate computation. Even a UDP app. can try to benefit from this (such as for communication where bounded delay is more critical than packet loss). Other `traffic conditions' input can also be fed into this module [perhaps as part of some future routing protocol]. Combining this `quality' of a route aspect into routing protocols may make sense in the long run.... -- bakul