Subject: Re: support for packet drop priority

From: [email-masked] (Konstantinos Dovrolis)
Date: Tue, 3 Feb 1998 14:28:59 -0600

> 
> Just because the port number says "FTP" doesn't mean the source of that
> traffic is well-behaved -- it might be using an implementation of TCP that
> has been hacked to be overly aggressive.
> 
> Also, if you blacklist some ports, the apps using those ports will just
> migrate to using non-blacklisted ports.
> 
> It's the actual, observable behavior that matters, not the port numbers
> that are being used.
> 
> Steve
> 

Steve,

Let me start from your last point. I totally agree that we need mechanisms
that monitor the actual behavior and not the "social cast" label (i.e. port#).
Such mechanisms are (or at least they should be...) one of the top priority
problems to solve these days. RED is such a mechanism, but I am not sure
that it is "active" enough in punishing only the "bad" guys, and isolating
the "good" ones.

However, the isolation based on port numbers _is_ a solution. A first-order
one, and as Jon said, a short-term one, perhaps, but I think
it is a practical solution. The reasons:

a) We have to trust  in a certain degree the TCP implementations. They
are written by OS vendors, and an OS vendor cannot (for many political
reasons) say that "I ignore slow-start and congestion avoidance". 
Of course there are cases where they try to play it smart and do their
own variations, that eventually lead to more aggressive TCPs (in other
cases they just have bugs; for details see Vern's TCP-related Sigcomm97
paper). Also, there is surely the possibility that a hacker that has
access to the kernel (or that uses a machine without kernel mode...)
can write his own TCP code. Possible, but this cannot bring the Internet
down, or even to make a big difference in a Mbps/Gbps link. This possibility
existed all the time after 1988 when the slow-start stuff first got deployed.
Besides, networks do not really operate on a stand-alone basis; the 
people that do the network monitoring can trace these "attacks", as long
as they do not happen all the time.

b) Regarding your point:
> 
> Also, if you blacklist some ports, the apps using those ports will just
> migrate to using non-blacklisted ports.
> 
What would happen in practice is to "whitelist" some ports and treat
all other ports as they are in the "blacklist". An app cannot migrate
to a whitelisted port. Unless of course if you assume that a hacker
that has access to both the sender and receiver machine kernels
has changed the mappings between port numbers and server deamons. 

c) In general:
Yes, one can always find ways to hack the network. This is the price
of simplicity. I think that this is a well known principle in the
Internet architecture. The more you push complexity and policy to the
edges, the more you make vulnerable the core. If we don't like this,
(I am afraid that...) we have to make the Internet as complex as
the telephone network is.

Constantinos

---

From: Zheng Wang <[email-masked]>
Date: Wed, 04 Feb 1998 13:56:48 -0500

Konstantinos Dovrolis wrote:
 
> a) We have to trust  in a certain degree the TCP implementations.  

Well, you can trust TCP implementation but what do you do 
with people who open multiple parallel TCP connections in order to 
gain unfair share of the bandwidth?

Cheers
Zheng

-- 
Zheng Wang                  
Bell Labs Lucent Technologies
http://www.bell-labs.com/user/zhwang

---

From: Geoff Huston <[email-masked]>
Date: Thu, 5 Feb 1998 09:49:52 +1100 (EST)

> gain unfair share of the bandwidth?

Well you asked:

Use a pricing structure which allows the provider to generate more
revenue in response to the greater volume of data being passed which
in turn allows the provider to deploy wider pipes to meet the
increased load.

I don't honestly see why the protocol should be pushed through all
kinds of unnatural hoops to attempt to solve non-problems. The _real_
question is the desired unit of fairness - the answer is that the
protocol has no knowledge of the mythical 'user', letalone how to
allocate resources fairly between multiple such 'users'.

Geoff Huston

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 04 Feb 1998 23:07:14 +0000

Zheng

scaleable aggregation policing, a.k.a drop, relies on some sort of gam
e theoretic superiority of the tactic and strategy of the net over the
end system behaviour (a.k.a trust)

 cheers

   jon