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

Lachlan Andrew lachlan.andrew at gmail.com
Wed May 14 19:13:32 BST 2008


Greetings Bob,

2008/5/14 Bob Briscoe <rbriscoe at jungle.bt.co.uk>:
> At 19:40 08/04/2008, Lachlan Andrew wrote:
>> 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.

Agreed.  The "however you do it" referred to whether you cap
congestion or charge (senders) for it.  I don't see how that is a
protocol issue.  It is a billing + admission control issue, with both
options needing the same information at the network ingress.

Both options need IP changes, but I believe that the same changes
would suffice in each case.  Correct me if I'm wrong.

> But networks can't cap the amount of congestion a receiver receives. It's
> too late by then.

Why not?  If all packets are dropped after the congestion cap is met,
then the user will not be able to open any TCP sessions (or SIP, or
...), and so there will be no traffic.  Even most existing sessions
will time out due to lack of ACKs.

> Currently networks can only charge for ECN received
...
> 'denial of funds' attacks.
> Hence the need for a protocol to make _senders_ accountable for causing
> congestion. That's a really hard protocol problem.

Absolutely.  I'm all for re-ECN.  I just don't see a big difference in
the data-plane signalling needed for charging (of senders) versus
capping.  Obviously management plane signalling will be different, but
that is easy once changes to IP have been agreed on.

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



More information about the Iccrg mailing list