From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Tue Oct 04 2005 - 19:11:52 GMT-3
Hellow Simon and Yan,
Thanks to both for your replies. I'll respond to both sets of issues raised in the one mail to help keep this clear.
Yan commented the following:
Your #1. Two comments:
1.1. In your description you concentrate mainly on fragmentation, not
prioritization.
1.2 In my view, the presence of dual FIFO is not a must for
prioritizing
voice as long as there's only one DLCI used. If so, FRF.12 is not
necessary.
Simon commented the following ( my replies follow Simon's comments):
simon hart <simon@harttel.com> wrote:
Chris,
I guess you could use priority queueing as well, classify your rtp traffic
in an ACL and direct all your voice traffic to the high queue. Not as
efficient as the others method specified as there would be no packet
interleaving and hence you could experience jitter through head of line
blocking.
With respect to point 1. I was unaware that FRF.12 by itself creates two
queues, that is one for packets below the fragment size and those above, my
understanding was that large packets got fragmented just so that smaller
voice packets could get interleaved - all packets then went to one WFQ
queue - do you have any links that explain this in more depth?
With respect to point 2. My understanding here was that with the
introduction of the frame-relay ip rtp priority command you create a high
priority queue within WFQ, and then you voice traffic would get pointed to
that queue.
Simon
Chris responds:
I would strongly suggest familiarity with the document:
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a00800a4754.shtml
The key point for both sets of comments is that either by enabling FRF.12 OR ip rtp priority, a dual FIFO on the interface is created.
If you create the dual FIFO with just FRF.12 (the fragment option in the map-class) just packets below the fragmentation size get put in the high priority FIFO, all the rest go in the low priority. If you enhance this configuration by adding the ip rtp priority command (or indeeed replace the fragment command with ip rtp priority) admission to the high priority FIFO on the interface is restricted to those packets that match the port range defined in the ip rtp priority command.
The net result is that enabling FRF.12 in isolation can be viewed as a form of prioritization if you assume that the packets you want prioritized are below the fragmentation size, as those are the ones that will get put in the high priority interface FIFO, which is effectively a strict priority queue. By using the ip rtp priority command, the configuration gets a little smarter and more efficient about how packest get in to the high priority interface queue. The IP RTP command places RTP packets in the high priority interface FIFO regardless of fragmentation configuration, althouguh fragmentation configured in adddition does help with reducing latency for voice on congested interfaces.
For completeness, the option 3 I originally listed just refers to the MQC form of shaping for frame defined at the following link.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/frqosmqc.htm
So the two things I will add to my list are as follows:
Legacy Priority queueing is an option
Performance can be enhanced through use of voice-adaptive shaping/fragmentation which basically only fragments if voice or voice control packets are present in the priority queue. This is simply configured and defined at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_vats.htm
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of Chris
Lewis
Sent: 04 October 2005 18:18
To: ccielab@groupstudy.com
Subject: Options for prioritizing voice on frame connections
All:
I am aware of the following options for prioritizing voice traffic over a
frame relay DLCI. Does this look complete, or can anyone add to it?
1. Creating a separate high priority queue on the interface
This requires FRF.12 (fragment in the map-class).Data packets larger than
the packet size specified in the frame-relay fragment command are first
enqueued to a WFQ subqueue, whereas the smaller packest go to the high
priority queue. They are then dequeued and fragmented. After fragmentation,
the first segment is transmitted. The remaining segments wait for the next
available transmission time for that VC, as determined by the shaping
algorithm. At this point, small voice packets and fragmented data packets
are interleaved from other PVCs. With this interface level queueing
mechanism, small data packest also get in to the priority queue on the
interface if they are smaller than the fragment size.
2. This can be enhanced by adding frame-relay ip rtp priority. KNown as
VoIPoFR, this classifies VoIP packets by matching on the RTP UDP port range
defined in a Frame Relay map-class. All RTP traffic within this port range
is enqueued to a priority queue for the VC. In addition, voice packets go
into the high priority queue at the interface level. All other packets go
into the non-priority queue at the interface level.
3. The generic form of using MQC to identify voice traffic, then using a
policy-map to give this traffic priority treatment and applying the
service-policy to a class for the DLCI
4. PIPQ configured on the interface using the interface-queue priority
command and assigning a complete DLCI to the priority queue in its
map-class, this of course requires one to dedicate voice to a specific DLCI.
5. Using PPP to fragment and interleave, which is pretty much like F=plain
FRF.12 and assumes that packet size is enough of a differentiator to
separate voice and data packets.
Chris
---------------------------------
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3