QoS over a T1 (MPLS)

mzinz

Recently got several T1's online which goes over an MPLS cloud at the provider.

The provider gives a 50MB hand-off to my hub router at our datacenter.

I have my remote router configured to do QoS - at this moment it is prioritizing all voice-traffic, up to 300KB worth (so about 20% of the T1).

I know that in addition to that, the provider has a payable option where they will also prioritize voice traffic for you.

Here is my question:
Since I'm already prioritizing voice-traffic and sending it out first, would it make any sense to also have the provider implement QoS? It seems that if my router is sending the voice traffic out first, and the provider is doing FIFO, the voice traffic will already be sent first.

I've been testing it, and when I have a download going that maxes out the T1, my voice quality goes to absolute hell. I don't think that the other end is the issue (the 50M handoff), because it has tons of bandwidth available.

Anyone have any clue what could be happening here?

networker050184

If you are just using your own markings and the ISP is treating all your traffic as BE then you may have some voice issues.

You are kind of thinking of things on too small a scale it seems. Yes, if you prioritize on your link it will be good there, but think how many other links the traffic will traverse between sites. Your voice traffic may or may not be getting prioritized on those links.

Another thing to remember that just because you are sending the voice out prioritized, doesn't mean its coming back in with priority. When you are doing that large download the ISP is just sending all traffic to you first come first serve. So the voice is waiting in line with the rest of the transfer packets.

My suggestion is that if you plan on using voip over this connection pay the extra for the EF service.

mzinz

networker050184 wrote: »

If you are just using your own markings and the ISP is treating all your traffic as BE then you may have some voice issues.

You are kind of thinking of things on too small a scale it seems. Yes, if you prioritize on your link it will be good there, but think how many other links the traffic will traverse between sites. Your voice traffic may or may not be getting prioritized on those links.

Another thing to remember that just because you are sending the voice out prioritized, doesn't mean its coming back in with priority. When you are doing that large download the ISP is just sending all traffic to you first come first serve. So the voice is waiting in line with the rest of the transfer packets.

My suggestion is that if you plan on using voip over this connection pay the extra for the EF service.

Hi Networker. Yes, I am thinking too small scale. The real issue is that I don't have a good enough understanding of QoS.... yet.

The main reason I wasn't as worried about all the hops in between was because it is MPLS... When I do a tracert to my hub router, its only 2 hops away (1 hop to my edge router, next hop is the hub). I was thinking (my logic is probably wrong) that if I send out traffic with a priority, then it will be the first out. The provider MPLS routers will continue forwarding FIFO, so the voice traffic will stay "in the lead".

You're right though, on the way back, it could easily get lost in the congestion. But what if I configure QoS on my hub router, also?

Would you say that no-matter how much QoS I'm doing, there will not be a good solution aside from having the provider run QoS on their equipment? If so, that's fine, I just need to understand.

Also - will they just prioritize all voice traffic, or would I need to coordinate with them and have DSCP tags matching up, etc?

mzinz

I spoke to the provider. They will run QoS based off templates they have.

The only catch is our templates have to match, via IPP. I'm assuming that IPP is similar to DSCP...

Anyone have a link to documentation on IP Precedence configuration? It would be a huge help.

networker050184

I think the thing you are failing to realize is that there are going to be other customers traffic on these links also. Just because you are sending out your traffic prioritized, its going to hit a link where it may have to contend with other customers traffic. The provider is going to be prioritizing its customer traffic that has paid for EF service, so your voice traffic will be treated like everyone else's BE traffic if that is all you are paying for.

Now this doesn't mean you will have an issue on every call, but if you hit congestion you will. The only way to ensure your provide is giving your traffic priority is to pay for it.

networker050184

mzinz wrote: »

I spoke to the provider. They will run QoS based off templates they have.

The only catch is our templates have to match, via IPP. I'm assuming that IPP is similar to DSCP...

Anyone have a link to documentation on IP Precedence configuration? It would be a huge help.

Yes, IP precedence is like DSCP, its the earlier version and only uses the first three bits of the TOS field. So you are going to want to ensure you are marking your traffic EF (101110) or IPP 5 (101000).

kalebksp

mzinz wrote: »

The main reason I wasn't as worried about all the hops in between was because it is MPLS... When I do a tracert to my hub router, its only 2 hops away (1 hop to my edge router, next hop is the hub). I was thinking (my logic is probably wrong) that if I send out traffic with a priority, then it will be the first out. The provider MPLS routers will continue forwarding FIFO, so the voice traffic will stay "in the lead".

That's how MPLS is many times setup, it doesn't mean that your traffic only went through two routers. MPLS forwards packets based on the MPLS label and doesn't touch the IP header, therefor the TTL is not decremented and you won't see any of the MPLS core routers when you do a traceroute. (There is a different way off setting it up so you can see the other routers in a traceroute, but I doubt there are many ISPs that would set it up that way for a variety of reasons.)

NOTE: I'm oversimplifying that, but the technical details aren't really necessary in your situation.

kryolla

look into fragmentation and interleaving also. The TTL field is copied to MPLS label in ingress and copy back to ipv4 header in egress. The provider network is transparent to you that is why you dont see them (MPLS VPN). Do a traceroute on the PE router and you will see the labels

kalebksp

kryolla wrote: »

The TTL field is copied to MPLS label in ingress and copy back to ipv4 header in egress.

If it's left at the default settings, it can also be configured to set the MPLS TTL to 255 and leave the IP TTL alone completely. If the ISP were to leave it at the default and a customer did a traceroute you would see the PE, then timeouts for all the P routers, then the otherside of the MPLS cloud.

keenon

one thing you must factor in is that the SP is using TE in there cloud. so with no QOS support your traffic is probably being put in the SP default where your traffic could be taking slower and/or more loaded links. Being they support QOS i would suggest if not too much $ subscribe to it.

also your qos policy on the remote ends hopefully match.. 20%. my suggestion it to use a blanket percent based policy

mzinz

Thank you for all the suggestions - I'm having my provider create a custom QoS template for us which will prioritize RTP traffic.

One simple question I had:
After I match traffic, I can set precedence and also set priority. I assume that setting the precedence means that traffic in the queue will be sent first, but how does priority come into play? Will it only send traffic from that queue UP TO the specified priority?

ie (not correct syntax):
match RTP traffic
set precedence 5
set priority 300kbps

So if I have 500kbps of streaming voice and a 500kbps download occurring, would it prioritize 300kbps worth of voice, then do FIFO for all remaining traffic?

kalebksp

mzinz wrote: »

Thank you for all the suggestions - I'm having my provider create a custom QoS template for us which will prioritize RTP traffic.

One simple question I had:
After I match traffic, I can set precedence and also set priority. I assume that setting the precedence means that traffic in the queue will be sent first, but how does priority come into play? Will it only send traffic from that queue UP TO the specified priority?

ie (not correct syntax):
match RTP traffic
set precedence 5
set priority 300kbps

So if I have 500kbps of streaming voice and a 500kbps download occurring, would it prioritize 300kbps worth of voice, then do FIFO for all remaining traffic?

Precedence sets the IP Precedence in the IP header, it's for marking traffic when it first enters the network (be it from the Internet, WAN, or a local computer) so that devices that it later passes through don't have to spend the processing cycles to figure out how they should treat it.

Priority sets up a priority class that is sent before all other traffic, the 300 kbps is telling the device to allow up to 300kbps of that traffic to be sent, after 300kbps everything is dropped.

I recommend that you read up on QOS and implementing with Cisco before configuring it in a production environment.