[Iccrg] Heresy following "TCP: Train-wreck"

[Bob Briscoe]

Lachlan,

Just to be clear - we're not proposing charging for congestion like Kelly.

The reason we developed re-feedback was to be able to limit how much 
congestion each user causes.

It's an important difference. Like the difference between volume 
charging and volume capping.

We have also proposed a moving cap (using a single token bucket per 
user) that would never run out, just limit the congestion you cause 
to the fill rate if you exhausted it.

Finally, I don't think 'we' have to use WFQ as an interim solution - 
fortunately 'we' don't make that choice - operators have protected a 
better form of fairness than TCP's on the Internet with WFQ for many 
years. See previous posting.


Bob

At 19:12 04/04/2008, Lachlan Andrew wrote:
>Thanks for starting this thread, Matt.
>
>FWIW, I tend to agree with Bob that locking "bandwidth fairness" into
>the network is
>(a) not necessarily the sort of fairness that applications need
>and
>(b) hard to reverse when we finally do see what applications need.
>
>I agree that "TCP-friendliness" is overrated, but would be pushing the
>Kelly/Briscoe line of charging users for the congestion they cause,
>rather than arbitrarily limiting them to equality of a metric most
>users don't care about (instantaneous bandwidth).
>
>It may be sensible WFQ is used as an interim solution until we can get
>the network-wide agreement necessary for charging.  However, if we
>agree that charging is a better eventual solution, we should be
>careful not to lock in design decisions which will make it harder
>eventually.
>
>$0.02,
>Lachlan
>
>On 04/04/2008, Dirceu Cavendish <dirceu_cavendish at yahoo.com> wrote:
> >
> > Zeroing into the bandwidth metric, a per flow queueing would give routers
> > the power to share their link capacities however they find fit - WFQ,
> > max-min fairness, etc - independent of other factors, such as 
> sessions RTTs.
> > In this scenario, and aggressive congestion control would cause its own
> > traffic to be spilled, so "isolation" of sessions would be achieved.
>
>
>--
>Lachlan Andrew  Dept of Computer Science, Caltech
>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
>http://netlab.caltech.edu/lachlan

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196