Questions about Internet Packet Losses

[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