Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May

[Bob Briscoe]

Lachlan,

inline...


At 22:33 07/04/2009, Lachlan Andrew wrote:
>Greetings Bob,
>
>2009/4/8 Bob Briscoe <rbriscoe at jungle.bt.co.uk>:
> >
> > 1/ Get operators to understand the benefits of moving from policing volume
> > to policing congestion-volume, initially by counting congestion locally at
> > congested resources (ie without transparency of policing to the end-user,
> > which they don't care about now anyway).
> >
> > 2/ Develop new (1/p) transports with weight (constant of proportionality)
> > set low, to be close to equal rate with a competing TCP flow 
> under 'average'
> > conditions.
> >
> > Current volume policing will approximately incentivise these transports not
> > to set their weight too high without some special arrangement (eg. paying
> > more), merely because they will otherwise transfer lots of volume over time
> > and get stopped.
>
>Does that incentive require that the transport know the policing rules
>used by the operators?  A particular OS/stack can't evolve in time to
>reflect the gradual changes of throttling policy by different
>operators.  However, if it could, relying on the punishment would mean
>that the current incentive is simply to be as aggressive as possible,
>wouldn't it?

The key is that policing shouldn't just be a memoryless instantaneous process.

We've written this paper to show that a policer can be designed to 
gently take over enforcing a congestion response if the overall 
volume of congestion from one customer is excessive *over time*. But 
it makes it in the interests of stack designers to *at most* fly just 
below the radar of the particular policer it encounters at run-time 
(to avoid the additional drop from exceeding the policed limit).
"Policing Freedom to use the Internet Resource Pool"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#polfree>

Note however that policing can kick in because:
a) the transport is *set* aggressively at design time, or
b) because the transport is simply *used* excessively at run-time 
(e.g. users make their apps send too much data through the transport).

Corollary: a stack won't be designed to be as aggressive as possible, 
because it has to cater for a wide range of run-time circumstances: 
it doesn't know what the user might want to do in the future, so it 
doesn't want to run too close to the limit all the time and leave 
nothing spare for later.

>I think the current incentive not to be too aggressive is
>over-buffered low-speed dedicated access links (e.g. ADSL), where the
>user is only competing against its own flows.

My vision is an Internet that doesn't have to be constricted at the 
access. Rather than giving 100 users only 100M each from a 10G PON, 
they could all peak at 10G. I believe this would be possible if they 
were limited in the congestion they could cause over time in the 
whole Internet (including in their PON). Similarly for other shared 
access technologies like UMTS, WLAN, cable and so on. As access 
technologies get faster, we have to move away from relying on access 
rate restrictions to keep everthing well-tempered.

Incidentally, there is already an incentive for app writers to be as 
aggressive as possible (including auto-config to fit to the line they 
encounter at run-time). Although they don't necessarily consciously 
write apps to game the system, app code does evolve so that faster 
strategies get selected more often. An app opening more flows is one 
example. It's equivalent to setting a higher weight in a weighted transport.

Cheers


Bob

>Cheers,
>Lachlan
>
>--
>Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
>Swinburne University of Technology, Melbourne, Australia
><http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
>Ph +61 3 9214 4837

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research