Is it possible to give 30% of the bandwidth for voice and 70% for data? 887 Security Bundled

[bilalghayad]

Hi All;

Is it possible to be able to control the download traffic on the DSL router 887 Security Bundled, so I can give 30% of the downloaded bandwidth for the voice and 70% of the downloaded bandwidth for the data? So maximum data to take 70% of the download bandwidth speed?

How?

Regards

Bilal

[Peter Paluch]

Bilal,

You could theoretically configure policing in the ingress direction that limits the amount of data traffic entering the router to at most 70% of the bandwidth. However, the sad thing about this is that this won't help you much. The problem is at the opposite side of the link - the DSLAM. It will not know about your configuration, nor will it honor it, and it will still fill the link with data as they come from the ISP. The policing configured on your router in the ingress direction will limit the amount of data traffic forwarded to the inside network but the link may still get congested and the real proportion between data and voice traffic on the link itself may be very, very different.

The policing may have effect on TCP data streams in that they will necessarily slow down when excess segments are dropped by the ingress policing, so the TCP may actually slow down to roughly 70% of the link speed. However, the exact behavior can not be guaranteed, and moreover, this does not apply to any other streams, such as UDP.

You may nevertheless want to try it. The configuration would be as follows, assuming that your IP interface towards the ISP is Dialer0:

class-map match-any Voice
 match protocol rtp
policy-map Di0-in
 class Voice
   police cir percent 30
     conform-action transmit 
     exceed-action drop 
 class class-default
   police cir percent 70
     conform-action transmit 
     exceed-action drop
interface Di0
 service-policy input Di0-in

The class-map Voice may require tweaking, as the match protocol rtp is not guaranteed to catch all voice streams. And as I indicated before, this attempt may be futile - but at the same time, it may be worth trying, perhaps the results will improve enough for you.

Best regards,

Peter

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

As Peter correctly describes, trying to regulate link inbound bandwidth usage often doesn't work too well.

In practice, I've found you often need to police the inbound traffic at a rate lower (sometimes much lower) then you would think because you need to provide feedback to the sender before it fills your link beyond the bandwidth you want it to use.

As also noted by Peter, TCP traffic should slow its transmission rate when drops are detected.  This being so, often you can limit your inbound policer to target only TCP traffic.

Another approach I've used has been to shape outbound ACKs.  This can also regulate inbound TCP traffic bandwidth usage, but like inbound policing, it tends to be very inexact.

[bilalghayad]

Dears;

We are talking that this to be applied for TCP, right?

As I know that RTP is UDP, so how the below will work:

class-map match-any Voice
match protocol rtp

policy-map Di0-in
class Voice
   police cir percent 30
     conform-action transmit 
     exceed-action drop 
class class-default
   police cir percent 70
     conform-action transmit 
     exceed-action drop

interface Di0
service-policy input Di0-in

Another question: RTP range differs alot, so how the router will capture it properly? Again, it is UDP

I have another idea and I hope it can work:

Mostly the problem happens when using http, ftp, POP, IMAP and SMTP, correct? All of those are TCP (if I am not mistaken). If I was able to limit their utilization to be not more than 70%, I can guarantee that data traffic will not cause a trouble for the voice. What about this idea?

If it work, can I do limitation on those to avoid them using more than 70% (all of them not to use more than 70% of the bandwidth)?

Regards

Bilal

[John Blakley]

You can assign an access-list to your class map like:

access-list 101 permit udp any any range 16384 32767

You'll need to change your class-map Voice to "match-all" (the default) instead of match-any. In order to do this, you'll need to take it out of the policy-map first:

policy-map Di0-in

no class Voice

no class-map Voice

class-map match-all Voice

match protocol rtp

match access-group 101

policy-map Di0-in

class Voice

police cir percent 30

     conform-action transmit

     exceed-action drop

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

bilalghayad wrote:
 Dears;
We are talking that this to be applied for TCP, right? 

Principally, yes, although there are a few other non-TCP protocols that are flow rate adaptive.

As I know that RTP is UDP, so how the below will work:
class-map match-any Voice
match protocol rtp

policy-map Di0-in
class Voice
   police cir percent 30
     conform-action transmit 
     exceed-action drop 
class class-default
   police cir percent 70
     conform-action transmit 
     exceed-action drop

interface Di0
service-policy input Di0-in

That's hard to predict.  As Peter described, match protocol rtp might not identify all your VoIP flows, and even if it did, do we really need to limit it's bandwidth?  I.e., limiting non-VoIP traffic bandwidth is likely much more critical.

Unfortunately, as I've previously explained, policing other traffic, that's upstream of the policer, does not truly guarantee it won't consume the bandwidth you need for VoIP.

I have another idea and I hope it can work:
Mostly the problem happens when using http, ftp, POP, IMAP and SMTP, correct? All of those are TCP (if I am not mistaken). If I was able to limit their utilization to be not more than 70%, I can guarantee that data traffic will not cause a trouble for the voice. What about this idea?
If it work, can I do limitation on those to avoid them using more than 70% (all of them not to use more than 70% of the bandwidth)?

Again, the idea is good, but the problem is, also again, you're policing downstream of where the congestion may form.  It's better than nothing, but you're not able to really guarantee VoIP wouldn't be impacted.

[bilalghayad]

Thanks for all the help.

Another approach I've used has been to shape outbound ACKs.  This can also regulate inbound TCP traffic bandwidth usage, but like inbound policing, it tends to be very inexact.

* How this can be applied (as configuration)? And is it possible to apply both (outbound ACKs and the police cir percent)? Will it be better by using those two approaches?

Principally, yes, although there are a few other non-TCP protocols that are flow rate adaptive.

* So why we are applying it for RTP in the above example?

I agree with you that we do not need to limit the voice traffic, but we need to limit the data traffic. But I was thinking why we used in previous examples the RTP and why i see these examples "policy for rtp voice" in the google? That let me think if there is something special for UDP.

Again, the idea is good, but the problem is, also again, you're policing downstream of where the congestion may form.  It's better than nothing, but you're not able to really guarantee VoIP wouldn't be impacted.

* OK, what is required from ISP side to be done so we can apply a policy that help in the downstream "based on this ISP configuration"? We might ask the ISP what they have. Any advise in this direction?

I have another idea, is there an DSL router that is possible to be connected to two lines, so we can take from the ISP two links, and we can route the data traffic to one link via one DSL interface and the voice traffic to another link via the other DSL interface?

Because it is possible to ask the ISP to give us for example 1 Mbps through one link and another 1 Mbps through another link instead of taking 2 Mbps through one link only. But I prefer to have one router to do this instead of having two routers.

Regards

Bilal

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

 
Another approach I've used has been to shape outbound ACKs.  This can also regulate inbound TCP traffic bandwidth usage, but like inbound policing, it tends to be very inexact.
* How this can be applied (as configuration)? And is it possible to apply both (outbound ACKs and the police cir percent)? Will it be better by using those two approaches?

How?  You have a CBWFQ class map that matches against TCP ACK packets and a class policy that shapes them.  It works, but not very exactly.

Principally, yes, although there are a few other non-TCP protocols that are flow rate adaptive.
* So why we are applying it for RTP in the above example? 

It's done to preclude priority traffic from taking all the bandwidth.  However, if priority traffic is properly controlled, it shouldn't be necessary but it still can be used "just-in-case".  (NB: that's the reason for CBWFQ LLQs have an implicit rate limiter.)

Again, the idea is good, but the problem is, also again, you're policing downstream of where the congestion may form.  It's better than nothing, but you're not able to really guarantee VoIP wouldn't be impacted.

* OK, what is required from ISP side to be done so we can apply a policy that help in the downstream "based on this ISP configuration"? We might ask the ISP what they have. Any advise in this direction?

"Normal" outbound CBWFQ, on the ISP egress would work well.  Even something as simple as:

policy-map example

class VoIP

priority percent 30

class class-default

fair-queue

I have another idea, is there an DSL router that is possible to be connected to two lines, so we can take from the ISP two links, and we can route the data traffic to one link via one DSL interface and the voice traffic to another link via the other DSL interface?

That would work if you had two completely different address blocks or your provider is willing to separate traffic types.  (The latter, I would guess, would be even more difficult than getting your ISP to support minimum QoS policy.  Typical ISP "solution" is for your to "buy" more bandwidth from them.)