Re: [aqm] aqm Digest, Vol 1, Issue 7

dpreed@reed.com Wed, 20 March 2013 03:02 UTC

Return-Path: <dpreed@reed.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80ABE21F8CF8 for <aqm@ietfa.amsl.com>; Tue, 19 Mar 2013 20:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.371
X-Spam-Level:
X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e18NqN1OtoR8 for <aqm@ietfa.amsl.com>; Tue, 19 Mar 2013 20:02:21 -0700 (PDT)
Received: from smtp176.iad.emailsrvr.com (smtp176.iad.emailsrvr.com [207.97.245.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2AD21F8F1C for <aqm@ietf.org>; Tue, 19 Mar 2013 20:02:21 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp57.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E6A09F84A4 for <aqm@ietf.org>; Tue, 19 Mar 2013 23:02:20 -0400 (EDT)
X-Virus-Scanned: OK
Received: from legacy2.wa-web.iad1a (legacy2.wa-web.iad1a.rsapps.net [192.168.2.218]) by smtp57.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id C3C30F83AE for <aqm@ietf.org>; Tue, 19 Mar 2013 23:02:20 -0400 (EDT)
Received: from reed.com (localhost [127.0.0.1]) by legacy2.wa-web.iad1a (Postfix) with ESMTP id 9CF52E00B5; Tue, 19 Mar 2013 23:02:20 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Tue, 19 Mar 2013 23:02:20 -0400 (EDT)
Date: Tue, 19 Mar 2013 23:02:20 -0400
From: dpreed@reed.com
To: aqm@ietf.org
Cc: aqm@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20130319230220000000_71582"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
In-Reply-To: <mailman.5225.1363736608.3432.aqm@ietf.org>
References: <mailman.5225.1363736608.3432.aqm@ietf.org>
Message-ID: <1363748540.64155384@apps.rackspace.com>
X-Mailer: webmail7.0
Subject: Re: [aqm] aqm Digest, Vol 1, Issue 7
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Mar 2013 03:02:22 -0000

A problem with ECN is that it does not drain an already flooded queue, and depends (like RED) on the idea that one has a large queue in normal operation.  It is not obvious that sustaining a deep queue is a desirable state, especially when there are highly variable capacities along any path, as is the case where one link is more than 2x slower than the rest of the links.
 
If the dynamics of user loads are fractal, this will cause draining (and latency reduction) not to work.
 
If user loads are stationary gaussian and so forth, ECN can "tune" to relatively stable situations, but the queueing delay will be quite long end-to-end.
 
Since there is lots of evidence that user loads are fractal, dropping packets during sudden bursts will prevent sustained queueing, whereas ECN will not.
 
So a proper approach (in my opinion) on the "real" Internet (rather than a bunch of competing long-duration FTPs) requires keeping the queues so short that there is no real opportunity to benefit from ECN.
 
Hence - we need to really see what happens with *real* traffic loads, not simplified simulations.
 
Real traffic loads are fractal, and fractal loads do not generally obey the Gaussian style "law of large numbers" - multiple fractal flows are *rougher* not smoother than a single one.
 
So check your mathematical "intuitions" at the door.  Stop writing equations based on tractable analytic models, because actual traffic does not follow those models.
 
Yeah, the Bell Heads believe in never dropping packets.  So what.  The Internet is not about making them comfortable in their misunderstandings.
 
-----Original Message-----
From: aqm-request@ietf.org
Sent: Tuesday, March 19, 2013 7:43pm
To: aqm@ietf.org
Subject: aqm Digest, Vol 1, Issue 7



If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/aqm

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send aqm mailing list submissions to
 aqm@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://www.ietf.org/mailman/listinfo/aqm
or, via email, send a message with subject or body 'help' to
 aqm-request@ietf.org

You can reach the person managing the list at
 aqm-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of aqm digest..."
Today's Topics:

 1. Re: [tcpm] ECN support and usage on the Internet (Yuchung Cheng)
 2. Re: ECN support and usage on the Internet (Fred Baker (fred))
 3. Re: ??: [iccrg] [tcpm] ECN support and usage on the Internet
 (Jim Gettys)
 4. Re: ??: [iccrg] [tcpm] ECN support and usage on the Internet
 (Simon Barber)
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm