[Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

[Stephen Hemminger]

On Tue, 15 Mar 2011 18:34:10 +0200
Jonathan Morton <chromatix99 at gmail.com> 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



--