From: Chee Chew Leong (cleong3@csc.com)
Date: Wed Nov 22 2006 - 04:34:21 ART
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.
> > >
> > >
>
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART