Fwd: [Iccrg] Meeting in Tokyo, with Pfldnet, 20 May
rbriscoe at jungle.bt.co.uk
Wed Apr 8 00:41:56 BST 2009
At 22:33 07/04/2009, Lachlan Andrew wrote:
>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,
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"
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.
>Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)
>Swinburne University of Technology, Melbourne, Australia
>Ph +61 3 9214 4837
Bob Briscoe, Networks Research Centre, BT Research
More information about the Iccrg