On Thu, Feb 5, 2015 at 6:34 PM, Richard Shockey <richard@xxxxxxxxxx> wrote:
OK yes, My Netflix download is going to kill your VOIP call.
Yes, it may, though pacing traffic may help (see the sched_fq work in Linux).
RS > Well ..its always been more subtle than you think. You have to distinguish between a Voice OVER IP call aka Skype etc vs a “managed service” like Voice USING IP or VuIP which is an entirely different beast. Modern VuIP which is all of Cable Voice in Europe and the US VZ FIOS etc and VoLTE is managed and uses IP technologies such as SIP/IMS but the routing may or may not have anything to to do with BGP. And BTW you have to still do the first order number translation as well. AKA RFC 6116 ENUM or something new which we are actually debating in RAI.Its segmented managed traffic. Its not Netfilx killing Skype its Microsoft Apple Android Updates as well. We have no visibility on how the OS actually queues application packets if at all.
Yup; this is a problem in the upstream direction (so is not the case you state above, but the inverse case, typified by events such as some one emailing a pile of images to your friends/family, backup and similar operations.
One of the most common bottlenecks is the WiFi or cellular hop, and if the operating system does a single bloated FIFO drop tail queue discipline, you get into trouble.
On Linux, this queue discipline has historically been one called PFIFO_FAST, and implemented a large (typically 1024 packet) FIFO drop tail queue (with a little bit of diffserv thrown in for good measure).
Turning on a different queue discipline is a single configuration line, and it appears that people have been deciding to make fq_codel the default in various Linux distributions as of last fall (it has been the default in OpenWrt on routers for a while).
At some point, it may make sense to use a different queue discipline (sched_fq) as the default, but I think more testing is needed. That's a bit of a discussion better left to a different message.
Can't fix the queuing algorithm for just one interaction...
There is one important point about fq_codel that needs explanation, and part of why we call it "flow queuing" rather than "fair queuing". Here's my best stab at a simple description of fq_codel:
Flows are identified. The first packet(s) from new flows are scheduled before packets from flows that have built a queue. If a flow’s queue empties, it is eligible to again be considered a new flow. CoDel is applied to control the queue length in any flow. Result: timely delivery, and mixing of flows.
What effect does this algorithm have in practice? Here are some examples:
o real time isochronous traffic (such as VOIP, skype, etc) won't build a queue, so will be scheduled in preference to your bulk data.
o your DNS traffic will be prioritized.
o your TCP open handshakes will be prioritized
o your DHCP & RA handshakes will be prioritized
o your handshakes for TLS will be prioritized
o any simple request/response protocol with small messages.
o the first packet or so of a TCP transfer will be prioritized: remember, that packet may have the size information needed for web page layout in it.
o There is a *positive* incentive for flows to pace their traffic (i.e. to be a good network citizen, rather than always transmitting at line rate).
All without needing any explicit classification. No identification of what application is running is being performed at all in this algorithm.
You can still do explicit classification in addition to fq_codel if you want (it's need is greatly reduced and most people don't bother except when at very low bandwidths, such as low speed DSL connections).
We don't care if the audio packets are SIP VOIP, or Skype, or a webrtc audio stream; anything that is behaves as a network "good citizen" gets best treatment. A well controlled paced TCP stream will get the same treatment. And it reduces latency exactly for the packets that are most latency sensitive.
The reason I started pushing on this is that in the wake of Title II I am expecting a lot of people to be asking me to explain how the Internet worketh and this is precisely the sort of example that shows how (1) things are more complex than they appear, (2) how some sort of coordination is needed and (3) how the coordination needs to take less than five years to come to a decision.RS> You really really don’t want to go into the US NN debate. Been there done that. The people who would have called you already called someone else. The outcome here in the US after February 26 when the FCC Order drops is already predetermined. The Zombies take over (aka the lawyers) it goes back to the courts. Its totally partisan. Kabuki Theatre. Nothing happens. But Nothing is perhaps a reasonable outcome here. First do no harm.
I hope the explanation above helps...
- Jim
Richard ShockeyShockey Consulting LLCChairman of the Board SIP Forumrichard<at>shockey.usSkype-Linkedin-Facebook rshockey101PSTN +1 703-593-2683