On Tue, 15 Mar 2011 18:34:10 +0200 Jonathan Morton <[email protected]> wrote:
> > On 15 Mar, 2011, at 12:36 pm, Jim Gettys wrote: > > > 0) the buffers can be filled by any traffic, not necessarily your own > > (in fact, often that of others), so improving your behaviour, while > > admirable, doesn't mean you or others sharing any piece of your won't > > suffer. > > 1) the bloated buffers are already all over, and updating hosts is often > > a very slow process. > > 2) suffering from this bloat is due to the lack of signalling congestion > > to congestion avoiding protocols. > > I actually agree. I was looking at the various TCPs to see how well they > would respond to ECN, and ECN can only be created by some kind of AQM, even > if it's a braindead version of RED. > > Previously, I pointed out that there is no point in buffering more than about > 1-2 seconds of data, full stop - and that includes wireless and very-thin > links (eg. analogue modems). In most cases the appropriate buffering level > is less still. The fundamental limit is the initial-RTO at 2.5-3 seconds, > which happens to correspond to a notional lunar bounce; once the delay > exceeds that, you start to get symptoms of catastrophic runaway, from both > automatic and human feedback sources. > > The main concern actually seems to be "can we turn on ECN safely" together > with the related "how do we convince everyone to use ECN". Once ECN is > widely deployed, we can more easily convince the routing people that using it > might be a good idea, which is a gateway to AQM for people who are otherwise > skeptical about AQM. It is clear that concerns still exist for ECN > deployment, but that these might only be noticed and fixed by relevant people > once deployment actually happens. Chicken and egg... Anecdotally, I have > ECN turned on for most of my traffic, I suspect that not all servers I > communicate with respond to it, but I don't see any nasty problems. > > The other major concern is consumer CPE. Most of this is made by a > relatively small number of manufacturers, who are currently in the process of > IPv6 transition. I seriously think we should make recommendations to the > IPv6 testing guys. Manufacturers will realise that without a label > proclaiming IPv6 support on the box, they will have a hard time selling stuff > in the near future. They do seem to have a test which verifies that ECN > isn't cut away by a router, but this isn't very precise about ECN behaviour > under load. > > > So the question I have is whether there is some technique whereby > > monitoring the timestamps that may already be present in the traffic (and > > knowing what "sane" RTT's are) that we can start marking traffic in time > > prevent the worst effects of bloating buffers? > > The timestamps are not globally valid. You would need to observe each > individual flow and maintain some state about them. What's more, you can't > do this using stochastic flow discrimination as some AQMs do to avoid > state-related starvation. > > Further, I don't think there is even any specification of how quickly the > timestamps should advance - they are really there to disambiguate the RTT *to > the hosts* in a retransmission-rich environment. One host might advance it > every centisecond, another every millisecond, another might increment it > using a global packet counter rather than a timer. The only thing the > timestamps can't do is go backwards, so that they can serve a secondary > function related to LFNs, large windows, and stale packets from previous > connections. > > So timestamps give the host generating them a (much) better idea of RTT > (which is good news for delay-based and hybrid algorithms) though it can > still be fooled about minRTT if the queue starts full. They can't > realistically be used by routers without making some serious and fragile > assumptions. > > - Jonathan Although ECN is a good idea, it really doesn't help when the majority of machines have ECN support disabled. Looks like it is disabled by default in Windows: http://technet.microsoft.com/en-us/library/bb878127.aspx -- _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
