[Iccrg] An aggression metric?

[Michael Welzl]

On Jul 14, 2011, at 7:05 PM, Lisong Xu wrote:

> Hi Michael,
>
> This is an interesting idea. But it may be hard to get a single  
> number N, since this number may be different for different packet  
> loss rates and base RTTs.

Well, it could be a simple from-to range. But of course, we could find  
that, then, all mechanisms are in the same, huge range  :)


> A similar method is to compare the response function (where N is  
> also a function), which captures more information of the  
> "aggression" of a congestion control mechanism.

Hm, that's closer to Bob's proposal. Finer grained but less practical  
perhaps. Or maybe not.

More voices please: is this even relevant, important, worth  
investigating?

Michael



>
> Lisong
>
> On 7/14/2011 2:15 AM, Michael Welzl wrote:
>> 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
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> Iccrg at cs.ucl.ac.uk
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
> -- 
> Lisong Xu, Associate Professor
> Computer Science & Engineering
> University of Nebraska-Lincoln
> http://cse.unl.edu/~xu