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

[Bob Briscoe]

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