[tmrg] Fwd: An aggression metric?

Michael Welzl <michawe@ifi.uio.no> Thu, 14 July 2011 09:17 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: tmrg@ietfa.amsl.com
Delivered-To: tmrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A734B21F8AE1 for <tmrg@ietfa.amsl.com>; Thu, 14 Jul 2011 02:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0ubYPjjZXQh9 for <tmrg@ietfa.amsl.com>; Thu, 14 Jul 2011 02:17:23 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 27A0121F8AEA for <tmrg@irtf.org>; Thu, 14 Jul 2011 02:17:19 -0700 (PDT)
Received: from mail-mx4.uio.no ([]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1QhI2n-0006j7-FF for tmrg@irtf.org; Thu, 14 Jul 2011 11:17:17 +0200
Received: from 1x-193-157-199-2.uio.no ([]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.76) (envelope-from <michawe@ifi.uio.no>) id 1QhI2m-0001Q6-Qr for tmrg@irtf.org; Thu, 14 Jul 2011 11:17:17 +0200
Message-Id: <3422D48B-0F2C-4059-BE3A-717D08DED3CF@ifi.uio.no>
From: Michael Welzl <michawe@ifi.uio.no>
To: tmrg@irtf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 14 Jul 2011 11:17:16 +0200
References: <34351D14-848F-4C9D-879C-58B8A0EE8FE1@ifi.uio.no>
X-Mailer: Apple Mail (2.936)
X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 3 sum msgs/h 3 total rcpts 10859 max rcpts/h 36 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 7099739ABF209C9539B0FD406504A8781A32811C
X-UiO-SPAM-Test: remote_host: spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 61 max/h 5 blacklist 0 greylist 0 ratelimit 0
Subject: [tmrg] Fwd: An aggression metric?
X-BeenThere: tmrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: IRTF's transport modeling research group <tmrg@irtf.org>
List-Id: IRTF's transport modeling research group <tmrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/tmrg>, <mailto:tmrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/tmrg>
List-Post: <mailto:tmrg@irtf.org>
List-Help: <mailto:tmrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/tmrg>, <mailto:tmrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2011 09:17:26 -0000

Hi TMRGers,

I sent this message to ICCRG, but I think it should be of interest to  
TMRG'ers too, so here I'm forwarding it. Please carry out discussion  
on the ICCRG list, though.


Begin forwarded message:

> From: Michael Welzl <michawe@ifi.uio.no>;
> Date: July 14, 2011 11:15:19 AM GMT+02:00
> To: "iccrg@cs.ucl.ac.uk list" <iccrg@cs.ucl.ac.uk>;
> Subject: An aggression metric?
> Hi!
> Here's an idea. Our group's charter says: "The key goal of the  
> Internet Congestion Control Research Group (ICCRG) therefore is to  
> move towards consensus on which technologies are viable long-term  
> solutions for the Internet congestion control architecture, and what  
> an appropriate cost/benefit tradeoff is."
> For a "viable long-term solution", I think that the "aggression" of  
> a congestion control mechanism is important, but most evaluations  
> focus on its efficiency in terms of bandwidth utilization, fairness  
> among flows of their own kind, etc. By aggression, I mean:
> - what happens when it fights against a standard TCP?
> - what happens when it fights against its competitors, e.g. (insert  
> your favorite mechanism here)?
> It's not uncommon to have a diagram that shows one of these things  
> in papers too, but what would really be good, I think, would be to  
> have a unified way of looking at it - an aggression metric.  
> Something that lets me conclude that, e.g., CUBIC is 7-aggressive,  
> HTCP is also 7-aggressive (of course these two are surely equal! he  
> he :)  ), FAST is 3-aggressive, Westwood is 12-aggressive, whatever!  
> Something like that.
> Standard TCP could be the base unit (the number 1) here. We recently  
> finished a paper in which we present an extension of the TCP steady- 
> state throughput equation for multiple flows - i.e. from the packet  
> size, loss event rate, RTT, and now also the number of flows (N) and  
> the actual packet loss ratio, one can calculate the rate at which N  
> flows would send. This is the paper:
> Dragana Damjanovic, Michael Welzl: "An Extension of the TCP Steady- 
> State Throughput Equation for Parallel Flows and its Application in  
> MulTFRC", accepted for publication in IEEE/ACM Transactions on  
> Networking, 2011.
> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5756471&tag=1
> The equation is also included in our MulTFRC draft:
> http://tools.ietf.org/html/draft-irtf-iccrg-multfrc-01
> (btw, we're just about to finish an update of this document, stay  
> tuned)
> It wouldn't be hard to turn this equation around such that, from the  
> packet size, loss event rate, RTT, packet loss ratio and sending  
> rate, one could calculate how many standard TCP's (N) must have  
> produced (or would be represented by) this rate. This would also  
> work with floats, e.g. a calculation could yield N=3.52 or something  
> like that. Thus, one could carry out a "benchmark test" simulation  
> of a high-speed mechanism where it's confronted with different loss  
> and RTT conditions, and from its resulting rate, one could then say  
> that it's between X and Y-aggressive, i.e. representing between X  
> and Y TCPs.
> Would that be a useful "aggression" metric?
> e.g. an alternative could be to produce a simpler equation which is  
> not so much based on all the specifics of TCP (slow start etc),  
> maybe just use N * MSS/RTT * (1/sqrt(p)), see where a modern TCP  
> with slow start stands in relation to that, and where high-speed  
> mechanisms stand in relation to that. Or should use an even simpler  
> equation?
> Do we even need or want such a metric?
> Cheers,
> Michael