From owner-freebsd-net  Mon Sep  7 23:46:04 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id XAA10980
          for freebsd-net-outgoing; Mon, 7 Sep 1998 23:46:04 -0700 (PDT)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA10923
          for <net@FreeBSD.ORG>; Mon, 7 Sep 1998 23:45:59 -0700 (PDT)
          (envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA16954; Tue, 8 Sep 1998 06:52:36 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199809080452.GAA16954@labinfo.iet.unipi.it>
Subject: Re: Will the TEE function of IPFW be ever implemented/necessary ?
To: archie@whistle.com (Archie Cobbs)
Date: Tue, 8 Sep 1998 06:52:35 +0200 (MET DST)
Cc: net@FreeBSD.ORG
In-Reply-To: <199809080550.WAA05485@bubba.whistle.com> from "Archie Cobbs" at Sep 7, 98 10:50:35 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> > > > as the subject says, i was wondering if the TEE function in IPFW
> > > > will be ever implemented. I cannot see what it can do that would not be
> > > > possible using bpf, and from the point of view of efficiency also there
...
> > > I think it makes sense to have it as an ipfw option.. the only
...
> > i'd like to get rid of it because it seems to be just a duplication of
> > functionality for something which is already available using bpf &
...
> I'd prefer that someone implemented it, because a few people have
> asked for it, but on the other hand if no one is even going to implement

yes but _how_ do people want to use it ?
Really, TEE is of very little use for everything i can think of,
because the user
 * cannot exercise any form of flow control;
 * is likely to get data out of order (depending on what happens
   in the network) and/or retransmissions;
 * has to separate data in the two directions, 

the policy that one wants to use for the above are so largely variable
that it makes little sense to put them in the kernel, and better rely
on a user-space process to do this. At which point, a BPF process would
be at least more portable to different architectures!

> it then it might as well go away (if you need the bit for something
> else, that is).

that's not a major issue since Poul solved the problem by widening
the field for ipfw commands in 3.0, and i have room for that in
-stable.

	cheers
	luigi

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message