[Iccrg] An aggression metric?

Thu Jul 14 23:28:18 BST 2011

(sending to ICCRG with Dirceu's permission)

Hi,

Regarding your first point about similar network conditions, I think  
the metric should be coupled with a simple "benchmark" test suite.

Regarding your second point, that such a metric "only serves to  
heighten the theoretical discussion about fairness", how do you think  
that developing more advanced schemes might make this discussion  
irrelevant?
I don't see how we would agree on a "perfect" level of aggression, as  
experienced by users running standard TCP. Isn't assigning a simple  
number to schemes as good as it gets, then?

Michael

On Jul 14, 2011, at 10:48 PM, Dirceu Cavendish wrote:

> Michael,
>
> Here is my two cents on the relevance of an aggressiveness metric.  
> For comparison purposes, any such metric (aM) will require similar  
> network conditions, e.g., sessions starting at the same time, ending  
> at the same time, same rtt, same packet loss probability, etc. To  
> me, such an aM metric has little practical relevance, as TCP  
> sessions sharing a bottleneck will rarely match these conditions  
> between them...Such a metric only serves to heighten the theoretical  
> discussions about fairness that, imho, may be straightjacketing the  
> development of more advanced TCP congestion control (CA) schemes.
>
> Rgds,
> Dirceu
>
> From: Michael Welzl <michawe at ifi.uio.no>
> To: Lisong Xu <xu at cse.unl.edu>
> Cc: "iccrg at cs.ucl.ac.uk list" <iccrg at cs.ucl.ac.uk>
> Sent: Thu, July 14, 2011 12:27:53 PM
> Subject: Re: [Iccrg] An aggression metric?
>
>
> 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
>
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg