how-to block ads
|
rradina
join:2000-08-08
Chesterfield, MO
1 edit | Does QOS really work?
I've read several comments in this thread regarding QOS and putting P2P at the bottom of the list. I certainly understand QOS in a corporate private network where IT is in control of the applications, protocols and ports being used across the link. How does this work in an environment where the applications, protocols and ports change like the wind? Isn't it like trying to catch a terrorist entering a stadium. Lots of people going in but it's tough to find that one nut job masquerading as normal. Certainly the security folks can profile guys who look like Osama Bin Laden but that will only guarantee the bad guys shave the beard and ditch the turbans. Now what?
In other words, if VOIP is prioritized, won't P2P try to masquerade itself as VOIP? Even if it cannot possibly do this, how about VPN? I use it all the time. How does the ISP know I'm not P2Ping through my VPN connection? Or will my VPN traffic now also be at the bottom of the list making working from home impossible during peak hours?
What if ISPs provided a way for customers to prioritize their own traffic? Obviously the honor system wouldn't work so there would have to be a way to manage it. Would an intelligent customer premises device (CPD) work? I know this could get potentially beyond the technical expertise of the masses but if we assume this is possible, now the customer can prioritize their own traffic and the CPD prioritizes the traffic at the link layer rather than the IP layer. If not the link layer, perhaps each CPD is given two IP addresses and based on customer configuration, the CPD controls which address (the high priority one versus the normal priority one) application-specific traffic uses. Combine this with a TOS that provides x-gigabytes per month of priority traffic. If you use it up, ALL your traffic is regular priority.
Now the customer can place their VOIP, video conferencing, VPN and other traffic at a priority while declaring their P2P traffic at regular priority.
No caps. No shaping. No net neutrality issues. The customer is in control. If they try to prioritize too much traffic, all their traffic goes to regular priority for the rest of the month. I know this is a bit like the FAP on satellite but I think it's different because the customer is in control. Along with each speed tier, the ISP could also offer the customer to pay for additional priority traffic. Again, the customer is in control and they can tailor their connection to meet their needs.
With this kind of arrangement, you could have the 7x24 torrent download at low priority -- getting whatever bandwidth is left -- but if you want the latest Linux distro now, hit a web page on the CPD, declare your torrent traffic as priority, grab the distro at full speed and then lower your torrent traffic back to normal.
If we get get this far, it wouldn't be much of a stretch to enable the CPD to publish HTTP-based web services to which applications could interface and start provide integrated prioritization. Now the masses have the "automatic transmission" they need because their applications can make it easy for them to choose high/low priority.
Am I dreaming? | |
factchecker
@cox.net
| said by rradina  :In other words, if VOIP is prioritized, won't P2P try to masquerade itself as VOIP? It could try, but it would fail miserably. The traffic/netflows for VoIP and P2P are completely different animals entirely. VoIP traffic is a constant and steady stream of traffic between two hosts, with a predictable data rate. P2P traffic is bursty, unpredictable and tends to move from host to host.
DPI can also spot the difference in the packets. VoIP audio is easily identifiable when examining packet payloads. | |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
 ·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
 ·Comcast
 ·Embarq
| said by factchecker :said by rradina :In other words, if VOIP is prioritized, won't P2P try to masquerade itself as VOIP? It could try, but it would fail miserably. DPI can also spot the difference in the packets. VoIP audio is easily identifiable when examining packet payloads. It's unrealistic to have core network devices doing DPI in most networks. Cisco has some base level detection with Network Based Application Recognition (NBAR), but it's nowhere near the analysis level of something like the Sandvine product.
DPI devices and high-performance routing devices are currently mutually exclusive. | |
factchecker
@cox.net
| said by espaeth :It's unrealistic to have core network devices doing DPI in most networks. Cisco has some base level detection with Network Based Application Recognition (NBAR), but it's nowhere near the analysis level of something like the Sandvine product. Indeed. I was just pointing out, however, that DPI gear can spot the differences quite easily.. | |
karlmarx
join:2006-09-18
iraq
·Fairpoint Communic..
| Yes, DPI gear CAN detect the difference, IF IT'S UNENCRYPTED. otherwise, it all looks EXACTLY the same. The solution, of course, is that EVERY vendor of EVERY protocol will start to encrypt their traffic. Every web site will be https. Every VoIP call will be encrypted. Every telnet session will be SSL. Everything, everywhere to everyone will be encrypted. Then the ISP is back to square 1.
--
The happiest countries are the most secular. The struggle AGAINST corporations is the struggle FOR humanity! | |
factchecker
@cox.net
| said by karlmarx :Yes, DPI gear CAN detect the difference, IF IT'S UNENCRYPTED. That's when you start looking at things like the flows. VoIP has a pretty characteristic flow - a constant, X Kbps per second flow (depending on the codec used, of which only two or three are in wide use), typically with very little variation.
For P2P to look like a VoIP conversation, you would have to make your P2P client use those same, sub-150kbps flows... You would end up crippling the throughput of your clients.
Every web site will be https. Not likely to happen. For most content, HTTPS is overkill. Unless the client is transmitted back to the server or the server is transmitting client specific data, there is no reason to waste CPU resources encrypting a JPG that anyone can see.
Every VoIP call will be encrypted. Maybe one day, yes. But even then, just looking at the flow of packets, you could tell it is a VoIP call.
Every telnet session will be SSL.
We already have encrypted telnet... It is called SSH. And I can find it even though it is encrypted. You can't read the contents, but you can tell it is SSH traffic. | |
boastt
@comcast.net | reply to factchecker
isn't that how university P2P scanners work?
They notice random surges of large connections being made, and they figure its P2P- so they shut the connection down. | |
|
