Re: OT: FR fragment size consideration

From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Wed Nov 22 2006 - 08:58:19 ART

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
> 

-- 
Petr Lapukhov, CCIE #16379
petr@internetworkexpert.com

Internetwork 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