Re: OT: FR fragment size consideration

From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Thu Nov 23 2006 - 03:35:02 ART

Next message: Petr Lapukhov: "Re: auth-proxy method lists for authentication."
Previous message: haducbinh: "QoS Question"
Maybe in reply to: Alexei Monastyrnyi: "OT: FR fragment size consideration"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Actaully, i specifically has pointed out that WFQ is *Per-VC* queue
enabled by default when FRF.12 & FRTS are enabled :) Indeed, Dual-FIFO is
*interface* level queue...

2006/11/23, Chee Chew Leong <cleong3@csc.com>:
>
> Actually, when we use frame-relay fragment .... we get dual fifo on the
> interface (not wfq as mentioned).
>
> FRF.12 is using dual fifo on frame-relay.
>
>
> http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a00800a4754.shtml
>
>
>
>
>
>
>
> Alexei Monastyrnyi <alexeim@orcsoftware.com>
> 11/22/2006 09:18 PM
> Please respond to
> alexeim@orcsoftware.com
>
>
> To
> Petr Lapukhov <petr@internetworkexpert.com>
> cc
> Chee Chew Leong/ASIA/CSC@CSC, bmcgahan@internetworkexpert.com,
> ccielab@groupstudy.com, ivan@iip.net, nobody@groupstudy.com
> Subject
> Re: OT: FR fragment size consideration
>
>
>
>
>
>
> 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
>
> _______________________________________________________________________
> 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

Next message: Petr Lapukhov: "Re: auth-proxy method lists for authentication."
Previous message: haducbinh: "QoS Question"
Maybe in reply to: Alexei Monastyrnyi: "OT: FR fragment size consideration"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART