On Fri, 3 Apr 2015, Jonathan Morton wrote:

> I'd like them to put some sane upper bound on the RTT - one
> compatible with satellite links, but which would avoid flooding unmanaged
> buffers to multi-minute delays.

The problem is that there aren't any numbers that meet these two criteria.
Even if you ignore 10G and faster interfaces, a 1Gb/s interface withsatellite 
sized latencies is a LOT of data, far more than is needed to flood a 'normal' 
link

Even if you "assume" that a satellite link is never going to be faster than say 
100Mb/s, with 1s of RTT you have more than enough data to drive a small link 
into delays long enough to start triggering retransmission of packets. and 
that's assuming that you have your queues defined by byte count, not packet 
count (which adds another large multiplier based on the potential need to hold 
enough tiny packets to keep the link busy)

Then when you add in the fact that the download side is being generated by a 
server that legitimately coudl have a 10Gb/sec or faster pipe, and while it may 
not need to talk over a satellite at those speeds, even a terrestrial pipe 
around the world has a high enough latency to require a bandwidth-latency 
product to rivel or exceed the worst-case consumer satellite situation...

In addition, even if the buffers are byte-based and tuned for exactly the pipe 
size, you still have the firness problem. Sparse/short flows tend to be things 
that are much mroe sensitive to latency (DNS, HTMl pages that then trigger the 
loading of many resoruces, etc) so you really do not want to have them waiting 
behind bulk data flows. Since you can't trust any QoS markings set by someone 
else, it's not possible to statically configure things to 'just work'. The good 
news is that we now have a few different ways of activly managng the queues that 
work well, so we can move from figuring otu what to do to trying to convince 
peopel to do it.

If it really was as simple as there beign a reasonable cap, and beng able to get 
unabiguous congestion signals reliably, the problesm would have been solved 
years ago

David Lang