Subject: RE: The problem with tagging packets

From: [email-masked] (Kilkki Kalevi NRC/Hki)
Date: Tue, 11 Nov 1997 11:50:29 +0200

On 10 Nov 97 at 4:41 PM, Alessio Casati wrote:

> Can you indeed show me how by multiple drop levels you can prevent a
> malicious user from using more TCP connections?

Yes, I can, or more accurately, the use of more TCP connections is not a   
problem in case of multiple drop levels.

Now I must refer to my SIMA proposal (http://www-nrc.nokia.com/sima/). In   
SIMA every customer pays for an NBR (Nominal Bit Rate). Now let us   
suppose that two customers have the same NBR: the first one has only one   
TCP connection, whereas the other one has 10 TCP connections. Now in SIMA   
the DP level depends on the actual bit rate to NBR ratio. If we suppose   
that the NBR is related to the aggregate bit rate, the two customers get   
the same the DP for their packets iff the aggregate bit rate is the same.   
So the (average) rate of the only TCP connection of the first customer   
will be tenfold compared to each TCP connection of the second customer.

The conclusion is that there is no actual advantage for customers to use   
several parallel TCP connections.

.. Kalevi

---

From: "Alessio Casati" <[email-masked]>
Date: Tue, 11 Nov 1997 12:32:04 +0100

Kalevi, you service model is good and works, but also a profile meter based one
is good too, though it provides only In or Out semantic. I also content it is better.
The problem is your approach does not take TCP behaviour into account, and maybe
more useful to test also for the correct behaviour of a TCP connection rather than
just test on its rate. An aggressive implementation must be penalized.
We'd have to provide some support for it. In addition I would not lean for differentiating
the degree of badness of any user. You must make any user and implementation designer
aware the network is not going to tolerate any misbehaviour.

---

From: "Alessio Casati" <[email-masked]>
Date: Tue, 11 Nov 1997 15:39:08 +0100

I'm sorry.
For some reasons something was dropped an mistakes are in what I wrote.
So here is the correct version.

 Kalevi, you service model is good and works, but also a profile meter based one
 is good too, though it provides only In or Out semantic. I also contenD it is better.
 The problem is your approach does not take TCP behaviour into account, and IT maybe
 more useful to test also for the correct behaviour of a TCP connection rather than
 just test on its rate. An aggressive implementation must be penalized.
 We'd have to provide some support for it. In addition I would not lean for differentiating
 the degree of badness of any user. You must make any user and implementation designer
 aware the network is not going to tolerate any misbehaviour.