From owner-freebsd-hackers Wed Apr 7 4:37:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fep2-orange.clear.net.nz (fep2-orange.clear.net.nz [203.97.32.2]) by hub.freebsd.org (Postfix) with ESMTP id 8DE4814C8C for ; Wed, 7 Apr 1999 04:37:03 -0700 (PDT) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep2-orange.clear.net.nz (1.5/1.9) with ESMTP id XAA23757; Wed, 7 Apr 1999 23:35:02 +1200 (NZST) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.2/8.9.2) id XAA24633; Wed, 7 Apr 1999 23:34:46 +1200 (NZST) (envelope-from jabley) Date: Wed, 7 Apr 1999 23:34:46 +1200 From: Joe Abley To: Walter Hafner Cc: freebsd-hackers@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: IP Type of service (FTP proxy in German c`t) Message-ID: <19990407233446.A24511@clear.co.nz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Walter Hafner on Wed, Apr 07, 1999 at 12:14:28PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, If the intention is to accelerate downloads, then I don't think this proxy is going to do much. It might promote the treatment of packets outbound from the client if the rfc1349 precedence is set to 7, but it can have no control over the return packets -- and that's where all the data is on a download (which is what most people do). In networks which _do_ support aggregate treatment of packets based on the rfc1349 precedence or diffserv bits, the usual strategy is to enforce the setting of these bits on ingress to the provider's network from the customer. No sane network provider operates on the principle that their customers are (a) skilled enough or (b) honest enough to set the bits correctly themselves. Having said that, I don't believe that many significant networks do anything at all with the rfc1349/diffserv bits further than cisco's alleged special treatment of precedence-7 traffic which is used for routing protocols. Concert Internet Plus is a notable exception, but they do ingress policing and shaping. Just my $0.02. I'm not worried about _our_ network :) Joe On Wed, Apr 07, 1999 at 12:14:28PM +0200, Walter Hafner wrote: > The following message is a courtesy copy of an article > that has been posted to muc.lists.freebsd.hackers as well. > > So - it finally happened. > > The well known german computer magazine c't released an FTP proxy, that > sends requests with user-definable IP_TOS entries. > > The software (for Mac, Windows and Linux) is downloadable under > > http://www.heise.de/ct/ftp/99/07/194/ > > The text on the page (an excerpt from the article in the magazine), > roughly in english: > > : Surfing on the fast lane > : > : Faster downloads with 'Quaility of Service' > : > : Article from c't 07/99, p. 194 (ju) > : > : The FTP-Booster accelerates FTP-Downloads, by setting the ToS-bits of > : the IP-Header appropriately. After startup it runs as a FTP-Proxy-Server > : on 127.0.0.1, port 1414. It has to be added to the browser-preferences > : manually. > : > : The following customizations have to be made: type of connection and > : priority. > : > : Level 0 runs with normal speed, level 1 (bulk) slows down downloads. > : Levels 2-7 accelerate. Levels 3-7 are password protected. > : > : qos-lin.tgz Linux-version of the ftp-Booster > : qos-win.tgz Windows-version of the ftp-Booster > : qos-mac.hqx Mac-version of the ftp-Booster > > The passwords for levels 3-6 are phrases in older c't magazines, level 7 > is for the c't staff only. Imho it's just a matter of time, until all > the passwords are common knowledge or the software gets hacked and the > proxy is widely used. (I got the passwords for the levels 3-5 simply by > a "strings" ...) > > I tried the Linux version on a FreeBSD 3.1 box: > > tcsh > FTPBooster-linux -Modem:128 -Priority:2 > FTPBooster 1.0 1999 c't/Matthias Withopf > Gestartet auf 127.0.0.1:1414, Uebertragung 128 KBit/s, Stufe 2 - Priority 1... > > Well ... :-( > > The article states, that *BSD is the only operating system, that > supports a direct setting of the IP_TOS bits via "setsockopt". I donīt > know, whether that is true, but I truly and strongly second the comment > in /usr/include/netinet/ip.h: > > /* > * Definitions for IP precedence (also in ip_tos) (hopefully unused) > */ > > The c't proxy operates by bypassing the normal IP stacks of the > operating systems. c't claims, that in their tests, about 80% of all > routers honored the TOS flags. > > On a sidenote - I just checked the FreeBSD fcpd code and noticed, that > IP_TOS calls are in there already. > > > So, what's the purpose of this mail? I don't really know, to be > honest. I'd like to see a discussion on what to do now. Disabling the > TOS features? Adding switches to the main net applications that allow to > set the priority, too? Urging router manufacturers to disable priority > handling by default? > > Imho it's a very bad thing, that users can manipulate IP > priorities. Priority handling should be limited to specific > applications for which it is really needed! Something must be done > about this. Fast. > > Bye, > > -Walter [ adding "boosting" capabilities to the FreeBSD kernel - just to > be one step ahead. :-( ] > > -- > Walter Hafner__________________________________ hafner@in.tum.de > *CLICK* > "Multiple exclamation marks," he went on, shaking his head, > "are a sure sign of a diseased mind." (Terry Pratchett, "Eric") > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message