[Iccrg] Meeting agenda (really! :-) )

Bob Briscoe rbriscoe at jungle.bt.co.uk
Wed Oct 11 16:54:59 BST 2006


Michael,

1/ I have a paper close to finishing (just got friendly reviews back) that 
I would like to present. It deconstructs the dominant understanding of 
fairness used in congestion control, explaining why fair allocation of 
rates to flows is the wrong question. It explains why flows aren't entities 
that we would expect to be fair to (and rate is the wrong thing to allocate 
anyway).

It will help answer the question in this thread about striping aross 
multiple paths, and generally completely re-boots most people's 
understanding of fairness, showing just how impractical and unrealistic the 
current way we think about fairness is.

This work has huge implications on router-allocated flow rate fairness like 
XCP (and RCP if one allows that RCP has less ambitious fairness goals in 
the first place). It should get a good debate going.

This is also intrinsic to our deeply held views on the definition of 
congestion, so it will contribute strongly to that debate (Lou Burness's 
contribution to the mailing list debate on that ages ago seemed to go 
undebated).

2/ We may also have work presentable by Feb on what per datagram congestion 
'signalling' bandwidth is necessary for hi speed congestion control as flow 
rates increase. What do I mean by signalling bandwidth? As an example, 
packet discard or ECN gives 1 bit per packet of signalling bandwidth. FAST 
claims to use congestion loss to give multibit feedback per packet, but we 
aim to quantify what 'multibit' means in this case, and why you get less 
signalling bandwidth per packet from measuring congestion delay as link 
speeds increase. The aim is to quantify at what point congestion 
delay-based approaches would get less than 1 bit per packet signalling 
bandwidth. Finally, we have a hypothesis on how to solve the problem more 
generally, which we may have proved by Feb, but that's a bit ambitious.

So, for the moment, I'd rather just offer the fairness work, but watch this 
space.


Bob

At 21:08 13/09/2006, Michael Welzl wrote:
> > I think it would be interesting to try to come up with two things
> > 1. What we know. Known 'good' approaches - i.e. whats common to the
> > proposals out there.
>
>but what exactly shall we expect to learn from / accomplish with this?
>I mean, we can write an overview, looking at commonalities ... to
>be concrete, I think this can be something like "delay has been used
>as a congestion measure in ... Vegas, FAST, ... it has the following
>advantages, the following disadvantages..."  ... and so on and so forth.
>
>That might be nice, but I'm having a hard time imagining that this
>will take us anywhere. Also, such overviews exist - how much
>should the overview differ from, say, this one:
>http://transport.internet2.edu/transport-design-space.pdf
>or the others in our Wiki?
>
>And what would it accomplish that the others don't?
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>Iccrg at cs.ucl.ac.uk
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 





More information about the Iccrg mailing list