Re: OT: FR fragment size consideration

From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Wed Nov 22 2006 - 05:46:49 ART

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>:
>
> 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>
> Sent by: nobody@groupstudy.com
> 11/15/2006 02:44 AM
> Please respond to
> "Brian McGahan" <bmcgahan@internetworkexpert.com>
>
>
> To
> "Ivan" <ivan@iip.net>, <ccielab@groupstudy.com>, "Alexei Monastyrnyi"
> <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
>
> 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] On Behalf
> Of
> > Ivan
> > Sent: Tuesday, November 14, 2006 10:22 AM
> > To: 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
>
> _______________________________________________________________________
> 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.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