[Iccrg] Re: [tmrg] Fwd: An aggression metric?

[Michael Welzl]

Hi,

Thanks, I think that's going in the right direction!

A disadvantage of your proposed measure is that it's maybe too fine  
grained to be practical. v = K.sqrt(p)/R is still a function of p and  
R, whereas what I proposed before is a number, or a number range based  
on a benchmark test, leading to a simple statement like "the  
aggression of this mechanism is between X and Y".

Of course, with a generic statement like that, you lose some  
information, i.e. the function gives you a more precise notion of  
"aggression"...

What do we need? What do others think?  :-)

Michael


On Jul 14, 2011, at 12:22 PM, Bob Briscoe wrote:

> Michael,
>
> Congestion-rate fulfils the role of measuring the aggression of a  
> flow, doesn't it? And it is in objective units of b/s, avoiding  
> being relative to TCP which is what you're looking for.
>
> Congestion-bit-rate is the bit-rate at which congestion events  
> (losses or ECN marks) are generated or experienced, for a flow or  
> any other aggregate. It measures the response of bit-rate to  
> congestion, which is another way of saying aggression.
>
> In a fluid model, congestion-rate, v(t), is the instantaneous  
> product of bit-rate x(t) and congestion p(t):
> v(t) = p(t)x(t)
>
> At first I thought this wouldn't be right as a measure of  
> aggression, because for TCP it depends on congestion, so I was  
> trying to normalise it to be independent of congestion. However, I  
> realised dependence of aggression on congestion is a feature of TCP:  
> as congestion rises, aggression rises. Also, aggression depends on  
> RTT for TCP.
>
> Taking the simplest TCP macro-model:
>        x = K/(R.sqrt(p))
> where K is a constant, and R is RTT. Then the congestion-rate,
>        v = K.sqrt(p)/R
>
> For a proportionally fair congestion control that converges to a  
> rate independent of RTT:
>        x = wp
> where w is the weight (similar role to TCP's constant). Then  
> congestion-rate,
>        v = w
> That is, the weight is the aggression of this flow.
>
> Any use?
>
>
> Bob
>
> PS. Tx for cross-posting to tmrg - it flagged to me that I had  
> fallen off iccrg somehow.
>
>
> At 10:17 14/07/2011, Michael Welzl wrote:
>> 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.
>>
>> Cheers,
>> Michael
>>
>>
>> Begin forwarded message:
>>
>>> From: Michael Welzl <michawe at ifi.uio.no>
>>> Date: July 14, 2011 11:15:19 AM GMT+02:00
>>> To: "iccrg at cs.ucl.ac.uk list" <iccrg at 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
>>
>> _______________________________________________
>> tmrg mailing list
>> tmrg at irtf.org
>> https://www.irtf.org/mailman/listinfo/tmrg
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design