From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Wed Nov 22 2006 - 10:18:18 ART
Right, but it is not an interleaving, it is rather dequeuing logic... If
I get things right, with 1500 byte packet fragmented which started its
transmissions will never let small Telnet or Voice packet showing up in
the middle of transmitting to be interleaved with WFQ only.
Do I miss something?
A.
Petr Lapukhov wrote:
> 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
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART