From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Wed Nov 22 2006 - 08:05:06 ART
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
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART