[Iccrg] An aggression metric?

Fri Jul 15 03:57:33 BST 2011

Hi,

I am revising the TCP evaluation test suite draft (see
http://tools.ietf.org/html/draft-irtf-tmrg-tests-02), and implementing the
revised proposals in ns2.

This proposal for a "benchmark" test suite to look at an aggressiveness metric
is very similar to 
http://tools.ietf.org/html/draft-irtf-tmrg-tests-02#section-3.5

I will be working on this part shortly. What does the group think of the idea
presented in section-3.5 for this type of application?

Alternatives? Improvements? Enhancements?

Regards,

David

PS
Work on this test suite will be eventually available at
http://caia.swin.edu.au/ngen/tcptestsuite/

On Fri, Jul 15, 2011 at 12:28:18AM +0200, Michael Welzl wrote:
> (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?
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> 
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
David Hayes
Research Associate
Centre for Advanced Internet Architectures
Faculty of Information and Communication Technologies
Swinburne University of Technology, Australia
http://caia.swin.edu.au/cv/dahayes/
Alternate Email: david.hayes at ieee.org