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

[Bob Briscoe]

Lachlan,

Realised I never replied to this (catching up on old emails)...

At 19:40 08/04/2008, Lachlan Andrew wrote:
>Greetings Bob,
>
>On 08/04/2008, Bob Briscoe <rbriscoe at jungle.bt.co.uk> wrote:
> >  Just to be clear - we're not proposing charging for congestion like Kelly.
> >  It's an important difference. Like the difference between volume charging
> > and volume capping.
>
>I didn't mean to misrepresent you, but to me, that's an IETF-level
>"implementation detail", rather than an IRTF-level issue.  To be
>maximally useful, it should be something which affects the
>users'/applications' behaviour to avoid peak times.
>
>The key is that the quantity you are both sharing out (however you do
>it) is  *congestion*  rather than rate or volume.

True, but even we agree it should be possible to make transports 
accountable for causing congestion, this consensus on the _metric_ 
would lead very much into a knock-on _protocol_ issue:
"However you do it" is no good if there are zero pratical ways to do it.

The IRTF can't propose a metric for networks to arbitrate between 
users if networks can't see the metric (given current Internet protocols)...

The Internet was designed so only endpoints could see congestion - 
it's really hard for the network to intercept congestion feedback 
robustly. And if networks do use the feedback, it will just encourage 
receivers not to send feedback.

ECN helps, but even them, networks can only make receivers 
accountable for the congestion sent to them. Even with ECN, networks 
can't see congestion up ahead when accepting packets from the sender.

But networks can't cap the amount of congestion a receiver receives. 
It's too late by then. Currently networks can only charge for ECN 
received (as Kelly suggested). At first sight that looks like it 
creates the right incentives, but I don't believe the IRTF should 
propose something that _requires_ a very specific business model. 
Plus it would just lead to 'denial of funds' attacks.

Hence the need for a protocol to make _senders_ accountable for 
causing congestion. That's a really hard protocol problem.


> >  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.
>
>OK, but "we" have the choice of letting loose algorithms which will
>increase pressure to deploy it where it isn't already enabled, don't
>we?

True.


Bob


>Cheers,
>Lachlan
>
>--
>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