From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Wed Nov 22 2006 - 11:40:50 ART
With FR, the queuing mechanics have two stages. For interleaving to work
correctly,
both queues need to provide priority treatment for voice (small) packets;
1) Per-VC should be WFQ or PQ WFQ, to pemit small packets to be dequeued
ahead of large ones. This is per-VC prioritization, and if it's not enabled,
second queue
(dual FIFO) is useless, since small packets are delayed at VC level.
2) DualFIFO is used to actually interleave packets. Small packets dequeud
from WFQ/PQ are placed into high priority half of DualFIFO, and are sent
until this
queue becomes empty. This is interface level prioritization, and
interleaving
at the same time.
22.11.06, Alexei Monastyrnyi <alexeim@orcsoftware.com> NAPISAL(A):
>
> Right, but it is not an interleaving, it is rather dequeuing logic... If
> I get things right, with 1500 byte packet fragmented which started its
> transmissions will never let small Telnet or Voice packet showing up in
> the middle of transmitting to be interleaved with WFQ only.
> Do I miss something?
>
> A.
>
> Petr Lapukhov wrote:
> > when you configure "frame fragment xxx" under map-class, your PVC queue
> is
> > automatically converted to WFQ, hence permitting small packet to be
> dequeued
> > first.
> >
> > 22.11.06, Alexei Monastyrnyi <alexeim@orcsoftware.com> NAPISAL(A):
> >
> >> To make some traffic interleave, you have to place it to high-FIFO
> >> queue, via enabling LLQ/priority queue for that.
> >>
> >> A.
> >>
> >> Petr Lapukhov wrote:
> >>
> >>> With FR, enabling fragmentation automatically turns on interleaving at
> >>> interface level.
> >>> Actully, this is why Dual FIFO is enabled as interface-level queue.
> >>> Apparently,
> >>> fragmentation w/o interleaving does not make real sense :)
> >>>
> >>> With PPP Multilink a special interleaving queue (similar to Dual FIFO)
> >>>
> >> is
> >>
> >>> also created, however AFAIK you can not observe it with show commands.
> >>>
> >>> 2006/11/22, Chee Chew Leong <cleong3@csc.com <mailto:cleong3@csc.com
> >>:
> >>>
> >>> Does this means if you enable frame-relay fragmentation,
> >>> interleave will
> >>> be automatically kick in?
> >>>
> >>> As my knowledge, interleave need ppp multilink.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> "Brian McGahan" < bmcgahan@internetworkexpert.com
> >>> <mailto:bmcgahan@internetworkexpert.com>>
> >>> Sent by: nobody@groupstudy.com <mailto:nobody@groupstudy.com>
> >>> 11/15/2006 02:44 AM
> >>> Please respond to
> >>> "Brian McGahan" < bmcgahan@internetworkexpert.com
> >>> <mailto:bmcgahan@internetworkexpert.com>>
> >>>
> >>>
> >>> To
> >>> "Ivan" <ivan@iip.net <mailto:ivan@iip.net>>, <
> >>> ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>>,
> >>> "Alexei Monastyrnyi"
> >>> <alexeim@orcsoftware.com <mailto:alexeim@orcsoftware.com>>
> >>> cc
> >>>
> >>> Subject
> >>> RE: OT: FR fragment size consideration
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Fragmentation ultimately controls the amount of
> >>> time a
> >>> packet
> >>> will sit in the shaping queue while waiting to be sent to the
> >>>
> >> transmit
> >>
> >>> ring to be serialized.
> >>>
> >>> The typical situation is that you have priority
> >>> traffic
> >>> like
> >>> VoIP that you want to interleave between larger data packets. To
> >>> accomplish this you need to make sure that your fragment size in
> >>>
> >> bytes
> >>
> >>> does not exceed your Burst Committed (Bc) in bits. In other words
> >>> take
> >>> Bc/8 and that should be your maximum fragment size.
> >>>
> >>> The reason is that if a single packet takes more
> >>> than one
> >>> Tc to
> >>> be transmitted (i.e. the packet fragment is larger than the amount
> >>> of Bc
> >>> you can send in one Tc) the delay for a priority packet will be
> >>> increased. If your fragment size is less than or equal to your Bc
> >>> then
> >>> the worst case delay for a priority packet will be one Tc in the
> >>> shaping
> >>> queue plus the serialization of the interface.
> >>>
> >>>
> >>> HTH,
> >>>
> >>> Brian McGahan, CCIE #8593 (R&S/SP)
> >>> bmcgahan@internetworkexpert.com
> >>> <mailto:bmcgahan@internetworkexpert.com>
> >>>
> >>> Internetwork Expert, Inc.
> >>> http://www.InternetworkExpert.com
> >>> Toll Free: 877-224-8987 x 705
> >>> Outside US: 775-826-4344 x 705
> >>> 24/7 Support: http://forum.internetworkexpert.com
> >>> Live Chat: http://www.internetworkexpert.com/chat/
> >>>
> >>>
> >>> > -----Original Message-----
> >>> > From: nobody@groupstudy.com <mailto:nobody@groupstudy.com>
> >>> [mailto:nobody@groupstudy.com <mailto:nobody@groupstudy.com>] On
> >>> Behalf
> >>> Of
> >>> > Ivan
> >>> > Sent: Tuesday, November 14, 2006 10:22 AM
> >>> > To: ccielab@groupstudy.com <mailto:ccielab@groupstudy.com>;
> >>> Alexei Monastyrnyi
> >>> > Subject: Re: OT: FR fragment size consideration
> >>> >
> >>> > Fragmentation need to reduce latency delay during serizlization
> >>> phase
> >>> > packet
> >>> > out. In this phase digital representation of packet convert to
> >>> analog.
> >>> In
> >>> > this case CIR not plays any role.
> >>> >
> >>> > On Tuesday 14 November 2006 18:41, Alexei Monastyrnyi wrote:
> >>> > > Just a quick example here - physical interface with AIR 128,
> >>> one PVC
> >>> > > with shaping to CIR 64.
> >>> > >
> >>> > > map-class frame-relay FRF
> >>> > > frame-relay cir 64000
> >>> > > frame-relay bc 640
> >>> > > frame-relay be 0
> >>> > > frame-relay fair-queue
> >>> > > frame-relay fragment 80 <- based on CIR
> >>> > >
> >>> > > vs
> >>> > >
> >>> > > map-class frame-relay FRF
> >>> > > frame-relay cir 64000
> >>> > > frame-relay bc 640
> >>> > > frame-relay be 0
> >>> > > frame-relay fair-queue
> >>> > > frame-relay fragment 160 <- based on AIR
> >>> > >
> >>> > > Why second one is usually said to be recommended?
> >>> > >
> >>> > > Thanks in advance,
> >>> > > A.
> >>> > >
> >>> > > Alexei Monastyrnyi wrote:
> >>> > > > Hi Group.
> >>> > > >
> >>> > > > I have checked discussions happened to be on this topic
> >>> starting
> >>> from
> >>> > > > April but haven't found any clear understanding of how one
> >>> should
> >>> pick
> >>> > > > a fragment size with regards to CIR/AIR of the interface.
> >>> > > >
> >>> > > > DocCD and Odom's QoS Guide say that one should consider AIR
> >>> of the
> >>> > > > slowest end. In some scenarios CIR (shaping rate) is
> >>>
> >> considered
> >>
> >>> when
> >>> > > > picking fragment size.
> >>> > > >
> >>> > > > Could someone point to pros and cons of either approach?
> >>> > > >
> >>> > > > TIA,
> >>> > > > A.
> >>> > > >
> >>> > > >
> >>> >
> >>>
> >>>
> >> _______________________________________________________________________
> >>
> >>> > > > Subscription information may be found at:
> >>> > > > http://www.groupstudy.com/list/CCIELab.html
> >>> > >
> >>> > >
> >>>
> >>>
> >> _______________________________________________________________________
> >>
> >>> > > Subscription information may be found at:
> >>> > > http://www.groupstudy.com/list/CCIELab.html
> >>> >
> >>> > --
> >>> > Ivan
> >>> >
> >>> >
> >>>
> >>>
> >> _______________________________________________________________________
> >>
> >>> > Subscription information may be found at:
> >>> > http://www.groupstudy.com/list/CCIELab.html
> >>> <http://www.groupstudy.com/list/CCIELab.html>
> >>>
> >>>
> >>>
> >> _______________________________________________________________________
> >>
> >>> Subscription information may be found at:
> >>> http://www.groupstudy.com/list/CCIELab.html
> >>> <http://www.groupstudy.com/list/CCIELab.html>
> >>>
> >>>
> >>>
> >> _______________________________________________________________________
> >>
> >>> Subscription information may be found at:
> >>> http://www.groupstudy.com/list/CCIELab.html
> >>> <http://www.groupstudy.com/list/CCIELab.html>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Petr Lapukhov, CCIE #16379
> >>> petr@internetworkexpert.com <mailto:petr@internetworkexpert.com>
> >>>
> >>> Internetwork Expert, Inc.
> >>> http://www.InternetworkExpert.com
> >>> Toll Free: 877-224-8987
> >>> Outside US: 775-826-4344
> >>>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Petr Lapukhov, CCIE #16379 petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART