Re: [aqm] the cisco pie patent and IETF IPR filing

David Lang <david@lang.hm> Wed, 04 March 2015 09:43 UTC

Return-Path: <david@lang.hm>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCE31A1A7F for <aqm@ietfa.amsl.com>; Wed, 4 Mar 2015 01:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJCBvIFbcxMU for <aqm@ietfa.amsl.com>; Wed, 4 Mar 2015 01:42:59 -0800 (PST)
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5383E1A0354 for <aqm@ietf.org>; Wed, 4 Mar 2015 01:42:59 -0800 (PST)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t249gjEW007546; Wed, 4 Mar 2015 01:42:45 -0800
Date: Wed, 4 Mar 2015 01:42:45 -0800 (PST)
From: David Lang <david@lang.hm>
X-X-Sender: dlang@asgard.lang.hm
To: KK <kk@cs.ucr.edu>
In-Reply-To: <D11C0740.3B84%kk@cs.ucr.edu>
Message-ID: <alpine.DEB.2.02.1503040135570.26262@nftneq.ynat.uz>
References: <CAA93jw4zZXGn_z2_dBBMsKN-XdwP88Wt-ChvfWJgCtp=J+i0rg@mail.gmail.com> <473265656416337848@unknownmsgid> <D11C0740.3B84%kk@cs.ucr.edu>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/yMLzJriQHGP6RnOmlJDZInNAi6A>
Cc: bloat <bloat@lists.bufferbloat.net>, "aqm@ietf.org" <aqm@ietf.org>, Vishal Misra <misra@cs.columbia.edu>, Dave Taht <dave.taht@gmail.com>
Subject: Re: [aqm] the cisco pie patent and IETF IPR filing
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2015 09:43:01 -0000

On Wed, 4 Mar 2015, KK wrote:

> Date: Wed, 04 Mar 2015 01:01:19 -0800
> From: KK <kk@cs.ucr.edu>
> To: Vishal Misra <misra@cs.columbia.edu>du>, Dave Taht <dave.taht@gmail.com>
> Cc: "aqm@ietf.org" <aqm@ietf.org>rg>, bloat <bloat@lists.bufferbloat.net>
> Subject: Re: [aqm] the cisco pie patent and IETF IPR filing
> 
> I think a combination of PI/PIE/fq_codel with ECN would enable us
> a) be less dependent of the physical amount of buffering that is
> implemented on the intermediate devices
> b) allow us to use buffering for what it is meant to do - ride out
> transient variations in traffic, at points where there is a mismatch in
> available capacity

The question is how much of a burst should the buffer be able to handle? Right 
now buffers routinely hold 10+ seconds worth of traffic (and Dave T showed the 
airline system buffering 10+ MINUTES of traffic)

The problem is that if you buffer too much, you break the TCP link speed 
probing, and if you buffer even more you end up with the sender genrating a new 
packet to deliver while you still are buffering the old one.

Buffers need to hold less than one second worth of traffic, and emperical 
testing is showing that much less is desirable (Others can post more exact 
numbers, but I belive that somewhere between 1/100 of a second and 1/10 of a 
second is a reasonable range)


> c) allow us to support different types of links, including wireless lossy
> links

If a retry is fast and has a very high probability of succeding, then it may be 
worth holding it and doing a link-level retry. But the existing mess that is 
wifi is hardly a good example of this being the right thing to do in a congested 
environment.

David Lang

> d) as we wrote in the ECN RFC, allow even short-lived transfers to not
> suffer
> Thanks,
>