From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Kalmer Date: Mon, 25 Apr 2005 07:48:20 +0000 Subject: Re: [LARTC] Spill over Message-Id: MIME-Version: 1 Content-Type: multipart/mixed; boundary="===============0919614172==" List-Id: References: In-Reply-To: To: lartc@vger.kernel.org --===============0919614172== Content-Type: multipart/alternative; boundary="----=_Part_5360_21792979.1114415300859" ------=_Part_5360_21792979.1114415300859 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Taylor & Chris (and the list) The arguments behind my choice here is cost driven, the 64kbps line is a=20 fixed monthly rate for unlimited use, the 512kbps line costs us roughly=20 ZAR250 per 3GB of usage. This can get quite expensive as the lines in=20 question is for a college and we all know what students do to bandwidth :) Taken the amount we pay every month for the 64kbps line it's more economica= l=20 to over utilize the link as a primary connection than to have it lying=20 around as a backup. South Africa and data connections don't go well in the= =20 same sentence... As Chris suggested, I need something that can detect when Link A is=20 saturated and then redirect the traffic over Link B until there is availabl= e=20 bandwidth on Link A again. The rate limit trick of Taylor might work once I= =20 get to understand the usage patterns of these students. But for at least th= e=20 first 3 months I won't have proper data at my disposal. Thanks for your replies! On 4/24/05, Chris Bennett wrote: >=20 > You can't split a particular IP connection between two links, but can=20 > instead only determine which link a particular connection will occur on.= =20 > Given this, it sounds like you want to have some way to detect that Link = A=20 > is already saturated and then send all further connections to Link B unti= l=20 > Link A is no longer saturated. > Maybe someone can tell you how to do that if that's really what you want= =20 > to do (others here know far more about this than me), but my guess is you= =20 > really don't want to do that. With the huge bandwidth disparity between t= he=20 > two links, route cacheing, and the inability know how much bandwidth any= =20 > particular conneciton will consume, I think you'd end up with a giant=20 > mess... those people with connections unlucky enough to end up on Link A= =20 > would probably be very unhappy people indeed. > Generally speaking I think it would make more sense to put all traffic= =20 > over Link B, and then use Link A only for emergencies. Maybe route the mo= st=20 > critical traffic over Link A if you really want to feel like its being=20 > utilized as something other than a pure backup, but personally I wouldn't= =20 > even do that. > Just because Link A is more reliable and more expensive doesn't mean it= =20 > makes sense to use it as your primary conduit. With Link B having eight= =20 > times the bandwidth, it seems the obvious choice as the primary. Use it, = and=20 > keep the users happy most of the time (instead of making them miserable m= ost=20 > of the time). On the rare ocassions it goes down, use bandwidth shaping t= o=20 > make sure the highest priority traffic gets access to Link A first. > In all the time I've used DSL, I've had severe outages twice for reasons= =20 > other than standard maintenance. In both cases (in two separate locations= ),=20 > the cause was the ILEC phone company mistakingly dropping the wire pair= =20 > while doing other work (freakin took over a week in each case to get my= =20 > connectivity back!!). This sort of thing could just as easily happen with= a=20 > leased line though, so I'm not really sure I buy that the leased line is= =20 > really more reliable than DSL line from a high quality ISP. Although mayb= e a=20 > particular SLA makes it so in some legal sense since you can then sue=20 > someone. Personally, if your leased line really costs more than the DSL, = I'd=20 > get rid of it and get a 2nd DSL line from another provider and use that a= s=20 > your backup instead. > Anyway, I guess my main point is that the high cost of your leased line= =20 > might be clouding your thinking on this. I wouldn't let the comparitive c= ost=20 > be your guiding light here. Go with what makes sense from a technology=20 > perspective, and don't guilt yourself into trying to get full utilization= =20 > out of the slow link just because it costs more. > =20 > ----- Original Message -----=20 > *From:* Kenneth Kalmer =20 > *To:* lartc =20 > *Sent:* Saturday, April 23, 2005 4:34 PM > *Subject:* [LARTC] Spill over >=20 > List >=20 > I need some help, advice or just a starting point on the following=20 > situation: >=20 > Link A - 64kbps leased line > Link B - 512kbps ADSL line >=20 > Is it possible to have Link A saturated constantly and have the excess=20 > traffic "spill over" onto Link B? I know it's possible to have packets se= nt=20 > down links in a round-robin fashion and I've read in the howto on load=20 > sharing over multiple interfaces ( > http://lartc.org/howto/lartc.loadshare.html), but I do not have control= =20 > over the termination of the link at the ISP's (two different one as well)= .=20 > Also note that splitting different protocols over each of these links are= =20 > not possible in our case. >=20 > Reason being, Link A is a more reliable and more expensive link, so I nee= d=20 > to over-use it's capacity if it we're, and use the cheaper ADSL (link B)= =20 > offering to keep al services running when the leased line (A) is saturate= d. >=20 > Any tips, suggestions and comments would be welcomed. >=20 > Regards >=20 > --=20 >=20 > Kenneth Kalmer > kenneth.kalmer@gmail.com > http://opensourcery.blogspot.com=20 >=20 > ------------------------------ >=20 > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >=20 >=20 > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >=20 >=20 >=20 --=20 Kenneth Kalmer kenneth.kalmer@gmail.com http://opensourcery.blogspot.com ------=_Part_5360_21792979.1114415300859 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Taylor & Chris (and the list)

The arguments behind my choice here is cost driven, the 64kbps line is a fixed monthly rate for unlimited use, the 512kbps line costs us roughly ZAR250 per 3GB of usage. This can get quite expensive as the lines in question is for a college and we all know what students do to bandwidth :)

Taken the amount we pay every month for the 64kbps line it's more economical to over utilize the link as a primary connection than to have it lying around as a backup. South Africa and data connections don't go well in the same sentence...

As Chris suggested, I need something that can detect when Link A is saturated and then redirect the traffic over Link B until there is available bandwidth on Link A again. The rate limit trick of Taylor might work once I get to understand the usage patterns of these students. But for at least the first 3 months I won't have proper data at my disposal.

Thanks for your replies!

On 4/24/05, Chris Bennett <chris@symbio.com> wrote:
You can't split a particular IP = connection=20 between two links, but can instead only determine which link a=20 particular connection will occur on.  Given this, it sounds like = you=20 want to have some way to detect that Link A is already saturated and then s= end=20 all further connections to Link B until Link A is no longer=20 saturated.
 
Maybe someone can tell you how t= o do that=20 if that's really what you want to do (others here know far more about this = than=20 me), but my guess is you really don't want to do that.  With the= =20 huge bandwidth disparity between the two links, route cacheing, a= nd=20 the inability know how much bandwidth any particular conneciton will= =20 consume, I think you'd end up with a giant mess... those people with connec= tions=20 unlucky enough to end up on Link A would probably be very unhappy people=20 indeed.
 
Generally speaking I think it wo= uld make=20 more sense to put all traffic over Link B, and then use Link A only for=20 emergencies.  Maybe route the most critical traffic over Link A if you= =20 really want to feel like its being utilized as something other than a pure= =20 backup, but personally I wouldn't even do that.
 
Just because Link A is more reli= able and=20 more expensive doesn't mean it makes sense to use it as your primary=20 conduit.  With Link B having eight times the bandwidth, it=20 seems the obvious choice as the primary.  Use it, and keep the us= ers=20 happy most of the time (instead of making them miserable most of the= =20 time).  On the rare ocassions it goes down, use bandwidth shaping to m= ake=20 sure the highest priority traffic gets access to Link A first.
 
In all the time I've used DSL, I= 've=20 had severe outages twice for reasons other than standard=20 maintenance.  In both cases (in two separate locations), the cause was= the=20 ILEC phone company mistakingly dropping the wire pair while doing other wor= k=20 (freakin took over a week in each case to get my connectivity back!!). = ;=20 This sort of thing could just as easily happen with a leased line though, s= o I'm=20 not really sure I buy that the leased line is really more reliable than DSL= line=20 from a high quality ISP.  Although maybe a particular SLA makes i= t so=20 in some legal sense since you can then sue someone.  Personally, if yo= ur=20 leased line really costs more than the DSL, I'd get rid of it and get a 2nd= DSL=20 line from another provider and use that as your backup instead.
 
Anyway, I guess my main point is= that the=20 high cost of your leased line might be clouding your thinking on this. = ; I=20 wouldn't let the comparitive cost be your guiding light here.  Go= with=20 what makes sense from a technology perspective, and don't guilt yourself in= to=20 trying to get full utilization out of the slow link just because it costs= =20 more.
 
----- Original Message -----
From:=20 Kenneth Kalmer
To: lartc
Sent: Saturday, April 23, 2005 4:3= 4=20 PM
Subject: [LARTC] Spill over

List

I need some help, advice or just a starting po= int=20 on the following situation:

Link A - 64kbps leased line
Link B = -=20 512kbps ADSL line

Is it possible to have Link A saturated constant= ly=20 and have the excess traffic "spill over" onto Link B? I know it= 's possible to=20 have packets sent down links in a round-robin fashion and I've read in th= e=20 howto on load sharing over multiple interfaces (http://lartc.org/howto/lartc.loadshare.html<= /a> ),=20 but I do not have control over the termination of the link at the ISP's (= two=20 different one as well). Also note that splitting different protocols over= each=20 of these links are not possible in our case.

Reason being, Link A = is a=20 more reliable and more expensive link, so I need to over-use it's capacit= y if=20 it we're, and use the cheaper ADSL (link B) offering to keep al services= =20 running when the leased line (A) is saturated.

Any tips, suggestio= ns=20 and comments would be welcomed.

Regards

--

Kenneth= =20 Kalmer
kenneth.kalmer@gmai= l.com
http://opensourcery.blogspot.com=20

_______________________________________________
LARTC mailing= =20 list
LARTC@mailman.ds9a.nl
 http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


_______________________________________________
LARTC mailing listLARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc





--

Kenneth Kalmer
kenneth.kalmer@gmail.com
http://opensourcery.blogspot.com ------=_Part_5360_21792979.1114415300859-- --===============0919614172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc --===============0919614172==--