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

[Michael Welzl]

Hi,

I fully agree (and more, I'm very happy about this proposal!),
if Keshav also does.

Cheers,
Michael


On Wed, 2006-10-11 at 17:54, Bob Briscoe wrote:
> 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