[LARTC] HTB burstable for 2 interface , how ?

[LARTC] HTB burstable for 2 interface , how ?

[rio]

Dear folks,
Here goes my bandwidth manager:

INTERNET
|
|eth0 202.14.41.1
BW.Manager
| |
| +----eth1----192.168.1.0/24
|
+------eth2----192.168.2.0/24

Total incoming bandwidth to eth0 is 1024kbps
should be shared to eth1 and eth2, which mean each get 512Kbps and
burstable to 1024Kbps if other host is idle.

My question is how do i apply HTB to these situation ?
As far as i know eth1 and eth2 should be define as parent and cannot be as
children.

Regards,
Rio Martin.



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[Stef Coene]

On Thursday 03 July 2003 10:56, rio@martin.mu wrote:
> Dear folks,
> Here goes my bandwidth manager:
>
> INTERNET
>
> |eth0 202.14.41.1
>
> BW.Manager
>
> | +----eth1----192.168.1.0/24
>
> +------eth2----192.168.2.0/24
>
> Total incoming bandwidth to eth0 is 1024kbps
> should be shared to eth1 and eth2, which mean each get 512Kbps and
> burstable to 1024Kbps if other host is idle.
>
> My question is how do i apply HTB to these situation ?
> As far as i know eth1 and eth2 should be define as parent and cannot be as
> children.
Indeed.  What you can do is use imq and add a imq device to your eth0.  
Redirect all incoming traffic to it and a htb qdisc to the imq device.  
Create 2 classes : one for eth1 and one for eth2.  And voila, eth1 and eth2 
can share 1024 kbps.
You can have a problem splitting the traffic in the classes because you don't 
know the src address when the packets enters your shaper.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[???????? ?????]

Well this can be done easily
You have to define a class having rate and ceiling 1024 kbps ( Kilobytes 
 if you want kilobits make its kbits ) in order not to exceed this limit.
Then you have to create two subclasses for the two networks by having as 
rate 512 and ceiling 1024. Then you must make the apropriate filters  
that will  classify the traffic in the right flows.
All theese for eth0.
So when the 192.168.1.0 is idle 192.168.2.0 will allocate all the 1024 
kbps bandwidth but when both will have traffic then they will take 512 each.

rio@martin.mu wrote:

>Dear folks,
>Here goes my bandwidth manager:
>
>INTERNET
>|
>|eth0 202.14.41.1
>BW.Manager
>| |
>| +----eth1----192.168.1.0/24
>|
>+------eth2----192.168.2.0/24
>
>Total incoming bandwidth to eth0 is 1024kbps
>should be shared to eth1 and eth2, which mean each get 512Kbps and
>burstable to 1024Kbps if other host is idle.
>
>My question is how do i apply HTB to these situation ?
>As far as i know eth1 and eth2 should be define as parent and cannot be as
>children.
>
>Regards,
>Rio Martin.
>
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>_______________________________________________
>LARTC mailing list / LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>  
>



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[Martin Devera]

you probably need IMQ if eth0 is input for your case

On Thu, 3 Jul 2003, rio@martin.mu wrote:

> Dear folks,
> Here goes my bandwidth manager:
>
> INTERNET
> |
> |eth0 202.14.41.1
> BW.Manager
> | |
> | +----eth1----192.168.1.0/24
> |
> +------eth2----192.168.2.0/24
>
> Total incoming bandwidth to eth0 is 1024kbps
> should be shared to eth1 and eth2, which mean each get 512Kbps and
> burstable to 1024Kbps if other host is idle.
>
> My question is how do i apply HTB to these situation ?
> As far as i know eth1 and eth2 should be define as parent and cannot be as
> children.
>
> Regards,
> Rio Martin.
>
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
>
>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[rio]

It wont work..
eth0 only for public ip traffic. It wont handle private network traffic.
Traffic to private network can be manage through eth1 & eth2

I guess the answer is IMQ .. i'll try ..
Documentation please, or perhaps docum.org already have documentation
regarding IMQ ?

Regards,
Rio Martin.


Original Message:
-----------------
From: ???????? ????? skekes@pylones.gr

Well this can be done easily
You have to define a class having rate and ceiling 1024 kbps ( Kilobytes 
 if you want kilobits make its kbits ) in order not to exceed this limit.
Then you have to create two subclasses for the two networks by having as 
rate 512 and ceiling 1024. Then you must make the apropriate filters  
that will  classify the traffic in the right flows.
All theese for eth0.
So when the 192.168.1.0 is idle 192.168.2.0 will allocate all the 1024 
kbps bandwidth but when both will have traffic then they will take 512 each.



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[Stef Coene]

On Thursday 03 July 2003 11:38, rio@martin.mu wrote:
> It wont work..
> eth0 only for public ip traffic. It wont handle private network traffic.
> Traffic to private network can be manage through eth1 & eth2
>
> I guess the answer is IMQ .. i'll try ..
> Documentation please, or perhaps docum.org already have documentation
> regarding IMQ ?
Not much.  I never had the time to try imq my self.  But it's easy.  
With imq you can create virtual devices and you can redirect any traffic to 
with iptables.  So you can redirect all incoming traffic to eth0 to the 
virutal device.  Shaping the traffic can be done by adding a htb qdisc to the 
imq device.  But in your case you will have a filter problem because you 
don't know the src address when a packet enter eth0.

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[Joel]

Hi martin,

Lot of linux users are using imq. But i dont have time to use it.
But yes You can do one thing.

Your case

etho----wan port  202.14.41.1

eth1---- 192.168.1.0/24
eth1:0---192.168.2.0/24

If you this 2 network connected within the same switch or hub then u can use
eth1 for both network if u have different switch or hub for this network
then y dont u put the cross cable between this two network and connect it
and then manage the bandwidth on both network.

give 192.168.1.0/24 bw 512
give 192.168.2.0/24 bw 512
and ceil it both to 512
and u know what u want to do ...when this network is not using the bandwidth
allow the other network.
its easy

u dont need to put the eth2 ..remove it...if u use the about example

Joel
----- Original Message -----
From: <rio@martin.mu>
To: <lartc@mailman.ds9a.nl>
Sent: Thursday, July 03, 2003 1:56 AM
Subject: [LARTC] HTB burstable for 2 interface , how ?


Dear folks,
Here goes my bandwidth manager:

INTERNET
|
|eth0 202.14.41.1
BW.Manager
| |
| +----eth1----192.168.1.0/24
|
+------eth2----192.168.2.0/24

Total incoming bandwidth to eth0 is 1024kbps
should be shared to eth1 and eth2, which mean each get 512Kbps and
burstable to 1024Kbps if other host is idle.

My question is how do i apply HTB to these situation ?
As far as i know eth1 and eth2 should be define as parent and cannot be as
children.

Regards,
Rio Martin.



--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] HTB burstable for 2 interface , how ?

[Don Cohen]

 > INTERNET
 > |
 > |eth0 202.14.41.1
 > BW.Manager
 > | |
 > | +----eth1----192.168.1.0/24
 > |
 > +------eth2----192.168.2.0/24
 > 
 > Total incoming bandwidth to eth0 is 1024kbps
 > should be shared to eth1 and eth2, which mean each get 512Kbps and
 > burstable to 1024Kbps if other host is idle.

This doesn't make sense to me.
The fact that an internal host is idle does not justify not sending
traffic TO it.

The suggestions to use IMQ+HTB seem to miss the problem that 
if someone sends 1024 to eth1 then nobody has a chance to even
begine to send anything to eth2.

I think you want to allow "borrowing" only as long as the total
incoming rate from eth0 is sufficiently less than 1024 to be sure
that those sending to the lesser used internal interface can speed up.
In effect I think you have to sacrifice some part of your 1024 to make
sure the shaping is done at your machine.  I'm not sure how much you
have to sacrifice.  But suppose it's 24K, so you then have two htb
classes that have rate 500, ceil 1000.  And the parent class also
has ceil 1000.  That's critical.  That means that if we send at full
rate to eth1 then we still have room for someone to start sending to
eth2.  Then when someone does start sending, he initially gets 24K to
eth2.  At that point HTB reduces the traffic to eth1 by 24K in order
to stay below total 1000.  Then the guy sending to eth2 can increase
by 24K which will cause eth1 to drop another 24, etc.
As you can see, the amount you "reserve" (you might say "waste") also
limits how fast the traffic equalizes.  

Does this make sense to everyone out there?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[LARTC] HTB burstable for 2 interface , how ?

[Leonardo Balliache]

Hi, Don:

  > INTERNET
  > |
  > |eth0 202.14.41.1
  > BW.Manager
  > | |
  > | +----eth1----192.168.1.0/24
  > |
  > +------eth2----192.168.2.0/24
  >
  > Total incoming bandwidth to eth0 is 1024kbps
  > should be shared to eth1 and eth2, which mean each get 512Kbps and
  > burstable to 1024Kbps if other host is idle.

 > This doesn't make sense to me.
 > The fact that an internal host is idle does not justify not sending
 > traffic TO it.
 >
 > The suggestions to use IMQ+HTB seem to miss the problem that
 > if someone sends 1024 to eth1 then nobody has a chance to even
 > begine to send anything to eth2.

Why not?

Ignore those bandwidth controller devices for a moment.

TCP flows compete to cope the available bandwidth. If your link capacity is 
1024kbit and you start sending 1024kbit to the interface eth1 and sometime 
later (the time you want) begin to send 1024 kbit to interface eth2, you 
can be truly sure that when flows stabilize each of them will be try to 
cope 50% of the available bandwidth defined by the link capacity. Finally 
each flow will be 512kbit.

Now put on your controller devices. They can control the upper level of the 
flows but no the flows themselve. TCP is always testing the bandwidth 
availability trying to get more share from it. What stop this? When a 
packet is dropped the inner congestion control mechanism is fired and TCP 
reduce automatically its rate. Finally the fight converge to every flow 
sharing the upper level defined by the controller device, as soon as those 
flows have enough packets to reclaim it.

Conclusion: use your bandwidth controllers but never forget the TCP natural 
behavior.

Best regards,

Leonardo Balliache




_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] HTB burstable for 2 interface , how ?

[Leonardo Balliache]

Hi, Don:

At 08:34 p.m. 07/07/03 -0700, you wrote:

>The point is that if X sends 1024 and Y tries to send 1 but fails,
>the firewall cannot tell and therefore can't do anything about it.

Which firewall? In case of having it doesn't have anything to do
here. Let's put aside any coercive device to concentrate in TCP
behavior.

>I'm not nearly as confident as you in the tcp mechanisms.  First,
>the upstream routers might favor one flow over another for whatever
>reason.  Second, even if tcp works as you'd like, the convergence will
>be much faster if there's some unused bandwidth.

Perhaps you are right, perhaps you are not. Who knows? TCP behavior
is a funny game with very clear rules. One of them is: first one that
loses a packet has to cut its rate by half. Who's lucky? Do you know?
Packets are dropped by routers in a random selection process. TCP
flows are always fighting to increase their shares. Sometime one of
them is ahead, but, it loses a packet. Like Monopoly. Walk back seven
step, man!! you are castigated.

>But I think that things really are stacked against the new flow.

Why? Are the routers conspiring against it?

>First the old one is going fast, and if it happens to lose a packet
>to the new one, it will probably barely notice, just receiving a sack
>and not slowing down.

** to the new one **

I going to understand ** to the old one **. Is not as easy. In fact TCP
congestion algorithms are far away for being easy. Simplifying, the game
is: if you lose a packet you have to cut your sending window by a half.
Check your new congestion window, check your outstanding packets, check
your peer advertising window, and depending of this, calculate how many
packets you can send, if you can send any, at all.

>However, in the reverse case, the new flow is
>starting slow, and if it loses a packet it waits for a timeout to send
>another one, then if it loses another it waits a longer timeout.
>Eventually, when the new flow tries to speed up it's always bumping
>against the old one, causing it to slow down again.

Probably the first flow has a higher probability to lose a packet because
it has more packets flowing out there. And if it happens, it has to cut
its window by a half. At this moment the second flow is at slow-start,
its window is increasing almost geometricaly (it doubles each time it
receives an ack). Again, who knows? The fight is fighting.

Timeout is an extreme case. Probably a duplicate ack advertises the flow
that one packet has been lost. Then slow-start is not the answer, just
fast retransmit and fast recovery and then congestion avoidance.

What about if the routers are RED routers. RED routers conspire (they
if fact are designed to conspire!!) against stronger flows, those that
maintain more packets in the router queue. Then the first flow has to
walk with care. Someone out there is tring to kill one of its packets.

>Are you really sure the system is guaranteed to converge to 50-50, or
>even to converge at all?  I'm not.  Please convince me.
>In any case, the firewall here is clearly not contributing to this
>since it's not dropping any packets, or even slowing them down.

Again any firewall doesn't matter.

I did some work to try to convince you. Have a look at
http://opalsoft.net/qos/TCPvsTCP.htm.

Finally, to close this pleasing conversation, don't forget that when
you configure your "controller devices" you are not controlling TCP,
you are just conspiring against it by killing some packets and using
the simple rule, "if you lose a packet, cut your window", to put under
control the average throughput.

Best regards,

Leonardo Balliache



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/