GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: OT: FR fragment size consideration posted 11/22/2006
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


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@xxxxxxxxxxxxxxx> 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@xxxxxxx <mailto:cleong3@xxxxxxx>>:
> >
> >     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@xxxxxxxxxxxxxxxxxxxxxx
> >     <mailto:bmcgahan@xxxxxxxxxxxxxxxxxxxxxx>>
> >     Sent by: nobody@xxxxxxxxxxxxxx <mailto:nobody@xxxxxxxxxxxxxx>
> >     11/15/2006 02:44 AM
> >     Please respond to
> >     "Brian McGahan" < bmcgahan@xxxxxxxxxxxxxxxxxxxxxx
> >     <mailto:bmcgahan@xxxxxxxxxxxxxxxxxxxxxx>>
> >
> >
> >     To
> >     "Ivan" <ivan@xxxxxxx <mailto:ivan@xxxxxxx>>, <
> >     ccielab@xxxxxxxxxxxxxx <mailto:ccielab@xxxxxxxxxxxxxx>>,
> >     "Alexei  Monastyrnyi"
> >     <alexeim@xxxxxxxxxxxxxxx <mailto:alexeim@xxxxxxxxxxxxxxx>>
> >     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@xxxxxxxxxxxxxxxxxxxxxx
> >     <mailto:bmcgahan@xxxxxxxxxxxxxxxxxxxxxx>
> >
> >     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@xxxxxxxxxxxxxx <mailto:nobody@xxxxxxxxxxxxxx>
> >     [mailto:nobody@xxxxxxxxxxxxxx <mailto:nobody@xxxxxxxxxxxxxx>] On
> >     Behalf
> >     Of
> >     > Ivan
> >     > Sent: Tuesday, November 14, 2006 10:22 AM
> >     > To: ccielab@xxxxxxxxxxxxxx <mailto:ccielab@xxxxxxxxxxxxxx>;
> >     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@xxxxxxxxxxxxxxxxxxxxxx <mailto:petr@xxxxxxxxxxxxxxxxxxxxxx>
> >
> > 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
>



-- 
Petr Lapukhov, CCIE #16379
petr@xxxxxxxxxxxxxxxxxxxxxx

Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Outside US: 775-826-4344