ietf
[Top] [All Lists]

Re: Naive question on multiple TCP/IP channels and please dont start a uS NN debate here unless you really want to.

2015-02-06 07:48:05
On Thu, Feb 5, 2015 at 6:34 PM, Richard Shockey <richard(_at_)shockey(_dot_)us> 
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 Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

<Prev in Thread] Current Thread [Next in Thread>