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

[Fred Baker]

On Mar 18, 2011, at 11:30 AM, Richard Scheffenegger wrote:

> 
> How about trying to push for a default, that the logical egress buffers are limited to say 90% of the physical capacity, and only ECN-enabled flows may use the remaining 10% when they get marked...

Lots of questions in that; 90% of the buffers in what? In a host, in a router, on a card in a router, in a queue's configured maximum depth, what? One would need some pedagogic support in the form of simulations - why 90% vs 91% vs 10% vs whatever?

> Someone has to set an incentive for using ECN, unfortunately...

Yes. From my perspective, the right approach is probably more like introducing a mark/drop threshold and a drop threshold. Taking the model that every M time units we "do something" like

      if queue depth exceeds <toobig>
         reduce M
         drop something
      else if queue depth exceeds <big>
         reduce M
         select something
         if it is ECN-capable, 
             mark it congestion-experienced
         else
             drop it
      else is below <hysteresis limit>
         increase M

the advantage of ECN traffic is that it is less likely to be dropped. That might be a reasonable approach.

> Richard
> 
> ----- Original Message ----- From: "Fred Baker" <fred at cisco.com>
> To: "Richard Scheffenegger" <rscheff at gmx.at>
> Cc: "Stephen Hemminger" <shemminger at vyatta.com>; "bloat" <bloat at lists.bufferbloat.net>
> Sent: Thursday, March 17, 2011 1:18 PM
> Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCPflavours - timestamps?
> 
> 
> 
> On Mar 17, 2011, at 5:05 AM, Fred Baker wrote:
> 
>> I'm very much in favor of ECN, which in all of the tests I have done has proven very effective at limiting queues to the knee. I'm also in favor of delay-based TCPs like CalTech FAST and the Hamilton and CAIA models; FAST tunes to having a small amount of data continuously in queue at the bottleneck, and Hamilton/CAIA tunes to a small bottleneck. The problem tends to be that the "TCP Mafia" - poorly named, but a smallish set of people who actually control widely-used TCP implementations - tend to very much believe in the loss-based model, in part because of poor performance from past delay-based implementations like Vegas and in part due to IPR concerns. Also, commercial interests like Google are pushing very hard for fast delivery of content, which is what is behind Linux' recent change to set the initial window segments.
> 
> I didn't say, and should have said: I'm also in favor of AQM in any form; I prefer marking to dropping, but both are signals to the end system. The issue is that we need the right mark/drop rate, and the algorithms are neither trivial nor (if the fact that after 20+ years Van and Kathy haven't yet published a red-lite paper they're happy with is any indication) well documented in the general case.=