Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Jul 2001 02:12:39 -0700
From:      "Ted Mittelstaedt" <tedm@toybox.placo.com>
To:        "kesu" <kesu@kesuki.dyndns.org>
Cc:        <freebsd-questions@FreeBSD.ORG>
Subject:   RE: Need help limiting bandwith ARP uses over cable modem.
Message-ID:  <00de01c118d7$c7afb160$1401a8c0@tedm.placo.com>
In-Reply-To: <20010729214847.X14350-100000@kesuki.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message-----
>From: owner-freebsd-questions@FreeBSD.ORG
>[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of kesu
>Sent: Sunday, July 29, 2001 8:05 PM
>To: Ted Mittelstaedt
>Cc: freebsd-questions@FreeBSD.ORG
>Subject: RE: Need help limiting bandwith ARP uses over cable modem.
>
>
>
>My incoming bandwith is 560 killobits/second my outgoing bandwith is 128
>killobits/second now surely you can see how receieving a saturating queue
>of packets on the inbound is going to generate _more_ outbound packets
>than my bandwith limitation.

No, actually I cannot.  If your RECIEVING a larger volume of data than your
sending then while you may be generating a lot of packets, those are SMALL
packets.

The packet count isn't what's important here - it's the size of the data
payload that matters.  An ordinary transmission such as an FTP session results
in very large, perhaps 1500 byte packets, coming down to you whereas your
sending acknowledgement packets back that are a tenth of the size.

> I am on average loosing 5% of all packets.
>

Well, what do you expect!!!  Why do you think your getting ARP requests to
start with?  ARP isn't used on point-to-point links it's only used on shared
media links like Ethernet and in your case Cable.  And shared media has a
thing called contention - this means that your cable modem and your neighbors
cable modem may transmit at exactly the same time, resulting in garbage on the
cable network as both packets are scrambled.  Packet loss here is normal.

>I have anylized the tcp stream intensively and the vast majority of arp
>requests are duplicates in the first place, likely built up in my isps
>queue dutrring the minuter it takes for a reconnect.
>
>There is a genuine need to restrict the ARP packets when my isp refuses
>to.

Your ISP cannot do anything here because Cable is a shared medium.

>I am not concerned about the bandwith loss coming inbound it is
>really the outbound traffic that is causing packet loss.  Restricting ARP
>has an emense benfit for cable modems,

Not if they are being operated in accordance with how the cable network was
designed.  Cable Internet service was designed to get large volumes of data
FROM the Internet TO your desktop, it was not designed to work the other way
around.

The only thing that I'll say about ARP restriction that's good is that it's
quite obvious that all your cable modem neighbors DON'T need to hear your ARP
broadcasts, and it's obvious that you don't need to hear theirs, because most
likely you and they are NOT exchanging data with each other.  But, this isn't
going to represent a significant bandwidth savings which is why the cable
Internet providers haven't bothered with doing it.  Cable Internet is a big
hack anyway and stories like this merely serve to illustrate that point.

> especially since they castrate the
>upstream levels, and there Is no isp choice.  Especially since the low
>grade copper to my house prohibits DSL.
>


The only possible way that restricting outbound ARP traffic would help you is
if your using your cable modem to host a server that is saturating the
outbound traffic with data transmission.  And I should remind you that @Home
explicitly bans cable users running servers I'll be happy to provide the URL
of the AUP if you don't believe me.

>I wouldn't have sent this e-mail if repeated letters of complaint to my
>isp hadn't failed to alleviate the problem for more than a week at a time.
>i need a _real_ solution, and controlling the bandwith ARP can use is the
>perfect solution.
>

The _real_ solution if your hosting a server is to quit violating your AUP and
get a real circuit in there like a Frame Relay circuit.  But if you don't want
to do that then I'd recommend you wait until 2002 (if your on the AT&T network
that is) when the cable net will be opened up to competitive ISP's and you can
get an ISP in there that's responsive - unlike @Home.  Then they can set your
upstream bandwidth to some pie-in-the-sky amount and you and your server can
stomp all over everyone else on the broadband.

Ted Mittelstaedt                                       tedm@toybox.placo.com
Author of:                           The FreeBSD Corporate Networker's Guide
Book website:                          http://www.freebsd-corp-net-guide.com



>--- 12:00PM up 22 days, 11:49, 11 users, load averages: 0.00, 0.02, 0.00
>Fortune of the day:
>Law of Selective Gravity:
>	An object will fall so as to do the most damage.
>
>Jenning's Corollary:
>	The chance of the bread falling with the buttered side down is
>directly proportional to the cost of the carpet.
>
>On Sat, 28 Jul 2001, Ted Mittelstaedt wrote:
>
>> How is any filtering that you do on your FreeBSD system going to affect the
>> incoming ARP packets?  They are STILL going to come in - even if you block
>> them, your blocking them after your modem has received them and so
>> accomplishing nothing.
>>
>> Even a crummy Pentium 200 can saturate a 10Mbt Ethernet pipe
>without noticing
>> it and I doubt that your getting even close that throughput
>delivered to you
>> via cable.  Your BSD Ethernet interface is literally loafing along
>when it is
>> recieving those 7,000 arp requests - it's not dropping the tcp packets as a
>> result of those.  If anything is, it's your cable modem.  Those
>recieved arps
>> are still going to be there whether you block them from your BSD box or not
>> and if your cable modem is being affected by them it will continue to be
>> affected by them, whether you block them or not.
>>
>> If you want to limit INBOUND arp bandwidth then complain to your ISP.  Of
>> course - you can limit outbound ARP bandwidth all you want - but
>unless your
>> system is screwed it's not transmitting 64k of outbound arps.  Further, I
>> doubt that the "consistent experience" your looking for is for OUTBOUND
>> bandwidth, I'm sure that what you care about is INBOUND bandwidth - and you
>> have no control over how much of a percentage of that is used by arps.
>>
>> Ted Mittelstaedt
>tedm@toybox.placo.com
>> Author of:                           The FreeBSD Corporate
>Networker's Guide
>> Book website:
>http://www.freebsd-corp-net-guide.com
>>
>>
>> >-----Original
>Message-----
>> >From: owner-freebsd-questions@FreeBSD.ORG
>> >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of kesu
>> >Sent: Saturday, July 28, 2001 3:24 PM
>> >To: freebsd-questions@FreeBSD.ORG
>> >Subject: Need help limiting bandwith ARP uses over cable modem.
>> >
>> >
>> >Well I have a very low bandwith cap on my cable modem, and as soon
>> >as the modem reconnects i am flooded with about 7,000 ARP requests.
>> >(in the first 3 minutes) this can literally cause any number of tcp
>> >packets to get dropped.  since arp tends to be more forgiving than
>> >tcp (especially for realtime situations) I would like to cap the
>> >ARP protocols bandwith usage to 64 Killobits per second in both
>> >directions over the cable modems interface.
>> >I have ipfw configured and in the kernel, and anyone who could tell me how
>> >to limit the bandwith of ARP would really help me get a more consistant
>> >experience from my cable modem.
>> >
>> >--- 12:00PM up 21 days, 11:49, 11 users, load averages: 0.00, 0.00, 0.00
>> >Fortune of the day:
>> >"I'm all for computer dating, but I wouldn't want one to marry my
>> >sister."
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-questions" in the body of the message
>


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00de01c118d7$c7afb160$1401a8c0>