Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt

gorry@erg.abdn.ac.uk Tue, 12 August 2014 07:35 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 C173F1A076E for <aqm@ietfa.amsl.com>; Tue, 12 Aug 2014 00:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 Wl2h0Ggx-K4C for <aqm@ietfa.amsl.com>; Tue, 12 Aug 2014 00:35:08 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2841A033A for <aqm@ietf.org>; Tue, 12 Aug 2014 00:35:08 -0700 (PDT)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 057F22B42E6; Tue, 12 Aug 2014 08:35:07 +0100 (BST)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 12 Aug 2014 08:35:07 +0100
Message-ID: <f7fd66505006abb58490a241cba55ee7.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <201408112045.s7BKjqYm022434@bagheera.jungle.bt.co.uk>
References: <20140805101838.24981.28443.idtracker@ietfa.amsl.com> <47c4f0afaec650af659401bf8a701596.squirrel@www.erg.abdn.ac.uk> <eda4a09fc0e144ed99cf9af5f41b6f26@hioexcmbx05-prd.hq.netapp.com> <201408110909.s7B99U7v020486@bagheera.jungle.bt.co.uk> <ff5e927945a46a39559fbb25b0ede6bc.squirrel@www.erg.abdn.ac.uk> <201408112045.s7BKjqYm022434@bagheera.jungle.bt.co.uk>
Date: Tue, 12 Aug 2014 08:35:07 +0100
From: gorry@erg.abdn.ac.uk
To: Bob Briscoe <bob.briscoe@bt.com>
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/aqm/A3FVLW09YivazcN37CVOzfVI8d0
Cc: gorry@erg.abdn.ac.uk, "Scheffenegger, Richard" <rs@netapp.com>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-07.txt
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: Tue, 12 Aug 2014 07:35:09 -0000

Bob - those changes are aded.

> Gorry,
>
> At 14:45 11/08/2014, gorry@erg.abdn.ac.uk wrote:
>> > Suggested text, respectively:
>> > * "The last two classes contain more aggressive flows
>> > that can pose  significant threats to Internet performance"
>> > * "The projected increase in the fraction of total Internet
>> > traffic for more aggressive flows in classes 2 and 3 could
>> > pose a threat to
>> > future Internet performance"
>>
>> > Note, I've also suggested changing 'stability' to 'performance' -
>> > this doc has nothing to do with oscillations, etc.
>>
>>+GF: Agree, this text was directly taken from RFC 2309… let's change it
>>... but how about “dependable performance”? (i'd like to capture that
>> this
>>isn't performance tuning - but more expectation of performance.
>
> Dependable performance isn't right. I'd leave it
> as just "...threat to ... performance".
>
> Any protocol or algo that gives you k/N share of
> available capacity doesn't give you dependendable
> performance, because N isn't under your control, only k.
>
I wasn't thinking that way - so I won't write that, I was wondering how to
write the opposite of lockout. Because performance is one aspect - but
methods to reduce synch and lockout are important also.

>
>>——
>>
>> > Responsiveness is important, but I believe it is OK for unresponsive
>> > flows that are small in relative terms to only be responsive at very
>> > long timescales (even solely at flow set up - self-admission
>> > control). This even applies to aggregates of unresponsive flows,
>> > because they will tend to be deployed where even the aggregate is
>> > small relative to the link capacity.
>> > See http://tools.ietf.org/html/draft-ietf-pwe3-congcons-02.pdf
>> > (comments to the PWE3 list pls).
>>
>>+GF: I don’t see this needed in this draft.
>
> Sorry, I was just reinforcing my point that "the
> sky is falling" language isn't necessary. I
> didn't intend to say there should be anything
> about any of the specifics in this para in the AQM draft.
>
>
>> > Bob
>>
>>——
>>
>>+GF: I’m also considering replacing /congestive collapse/ by /congestion
>>collapse/ which seems a more common term, as noted by John L.
>
> Works for me.
>
> Regards
>
>
> Bob
>
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>