Re: Re: Rate

--=-60JK9x+H1WpxGSdBkXL8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


> > Message: 2
> > From: "Alby" <[email protected]>
> > To: "Jeroen Steenhuis \(Dutch Plating Power BV\)" <j_steenhuis@dutchpla=
ting.com>,
> >         <[email protected]>
> > Subject: Re: [LRP] Rate
> > Date: Fri, 14 Feb 2003 07:57:07 -0500
> >=20
> >   That isn't possible unless its done from an application layer
> > that limits the download bandwidth used. Unless something has
> > changed, I don't know of any router which can tier bandwidth
> > based on what port a packet is using. Bandwidth can be tiered
> > per connection and/or network so that users on a certain network
> > are capped as a whole. Even so, I don't know if a LRP router can
> > do any of that.
> >=20
> >  Sorry Jeroen, about the best you can do is crack heads on downloaders
> > if they are hogging your bandwidth. Otherwise the only other possible
> > scenerio would be to setup a network design where each workstation
> > had its own router, and that router had a frame-relay pvc connection
> > back to a gateway router. With that, you could limit the "overall"
> > bandwidth per machine so that you allow enough to surf, but not
> > enough to eat up the network's total bandwidth. Maybe allocate
> > 10k per machine or some fraction of your total bandwidth. The down
> > side to that is amount of hardware you'll need to deploy. And I don't
> > know if an LRP router could run different protocols like FrameRelay
> > since the interface cards are ethernet. Frame-Relay over Ethernet,
> > I don't think its possible.
> >=20
> >  Before I start thumbing through my CCNA book and typing up more
> > jibberish, the overall answer I believe is (No).
> >=20
> > -Alby
>=20
> Without going into LRP specifically, this can be done in Cisco platforms,
> so I'm sure that there is a mechanism to achieve the same on LRP or like.
>=20
> In cisco terms its called policy routing.

2.4 kernel specific
 A byproduct of policy routing can be dropping packets which in turn
will slow senders down.I am amazed at how dropping packets is a common=20
implementation theory for Cisco, but that is another story. Policy
routing is only really useful where you have multiple egress pipes.
Linux has the ability to classify traffic down to the ip/port in either
direction of a flow and mark these packets for just about anything you
can come up with. Add on to that the ability to get real time stats and
dynamically change up flows based upon them is a beautiful thing, but
that is not what you need.
=20
 The ingress qdisc in the Linux kernel can be used to slow down an
inbound flow. By using tc filters to mark packets before they get to the
routers stack you can prevent any one flow from overwhelming a pipe.
Remember when doing traffic classification using any queuing mechanisms
it is important that you have a default class for all packets not
defined to use.=20

I would also recommend using the htb qdisc outbound in tandem with the
ingress qdisc. If you don't do both ways the sessions can get choppy. It
is very inefficient for hosts to change their flow rates too often for
smaller data transfers.

Remember that udp traffic does not shape as nicely as tcp. But that is
beyond the scope of this mailing list.

Ted=20



--=-60JK9x+H1WpxGSdBkXL8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA+T5U3J2b48cdRLp0RArADAJ9KDnUtqZklwCfwXQkf7p/U79ooxgCeLQ8G
Fy00lvKn7Jc2IwuxXiWj4z4=
=T31G
-----END PGP SIGNATURE-----

--=-60JK9x+H1WpxGSdBkXL8--


_______________________________________________
linux-router maillist  -  [email protected]
http://www.linuxrouter.org/mailman/listinfo/linux-router