|
|
This topic comprises 4 pages: 1 2 3 4
|
|
Author
|
Topic: SBC Global DSL SUCKS!
|
|
|
|
|
|
|
|
|
|
|
|
|
Joel N. Weber II
Expert Film Handler
Posts: 115
From: Somerville, MA, USA
Registered: Dec 2005
|
posted 08-18-2007 10:08 PM
quote: Rick Raskin
I'm curious what type of queueing that might that be if you are running native IP?
The answer I have heard is they over-engineer their core networks so that necessary bandwidth will be available.
If you're running a half dozen or fewer phone calls over a T1, the T1 has a ridiculous excess of bandwidth to carry those phone calls, as long as people surfing the web don't happen to have their packets delaying the phone traffic too much. (The original use of a T1 was to carry 24 simultaneous 56 kilobit per second phone calls using time domain multiplexing, after all.)
So ideally you want to convince the routers on both ends of the T1 circuit that they should separate the voice traffic from the other traffic, and if there's a voice packet waiting, to always send that before any random data traffic. (A packet-switched network such as an IP network typically will send one packet at a time; once you start sending a packet across the link, that packet monopolizes the link until you finish sending the entire packet. So it's just a matter of making better choices when you finish sending a packet and are trying to decide which packet to send next.)
Doing this right requires configuring this on your router, and persuading your ISP to do likewise. I suspect many business grade ISPs aren't prepared to do this.
There are a number of ways you might describe to the routers which traffic is high priority. Depending on the software on the router, you may be able to look at IP address, TCP/UDP port number, and the Type of Service byte (where you should actually only be using the 6 bit DSCP field), etc.
Thus far, I've only configured this on Cisco IOS routers. Cisco offers a ton of different queueing strategies (most of which don't solve the VOIP problems); I ended up using Low Latency Queueing, which gives you one high priority queue, and then randomly divides the rest of the traffic among many low priority queues so that if there are multiple low priority TCP streams, those low priority streams are likely to each get similar amounts of bandwidth. Cisco also has a strict priority queueing option that lets you divide the traffic into four levels of priority.
I've used a config that looks something like this:
quote:
class-map voip
match access-group 150
policy-map outbound-policy
class voip
priority 800
class class-default
fair-queue 64
queue-limit 20
interface serial6/0
service-policy output outbound-policy
You need to substitute the right interface name, and you need to define an access-list 150 that matches the traffic that cuts in line. And there was some slight change in syntax that was needed on the ISP end to be compatible with the software they happened to be running.
Juniper's ScreenOS offers 8 levels of strict priority queueing as its only queueing strategy (well, or you can put it into an extremely simple, dumb FIFO mode with no prioritization). However, I haven't yet managed to get that working for VPN tunnels. If you have a ScreenOS router sitting behind a Cisco IOS router, you can configure route based tunnels on the ScreenOS router, and the IP Type of Service field in the IP header leaks out to the unencrypted part of the encrypted packet where the IOS router will happily use it to prioritize the data appropriately, so that the voice traffic in the tunnel goes out ahead of the data traffic in the same tunnel. If you have a T1 card in your ScreenOS router, it appears to me that you have to define one tunnel for the high priority traffic, and another for the low priority traffic, and put those tunnels on different globally routed IP addresses so that you can tell the router to traffic shape on those addresses, and then use policy based routing to insert the traffic into the correct tunnel. However, I haven't tried that out yet.
| IP: Logged
|
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 4 pages: 1 2 3 4
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
![[Moon]](graemlins/moon.gif)
Printer-friendly view of this topic