From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Tue Nov 14 2006 - 16:05:08 ART
That is exactly what I was worrying about! Delaying parts of fragments
by shaper....
I didn't know that fragmentation ultimately controls shaping queue.
Thanks, Brian.
Then my previous post sounds naive. :-)
So, we take fragment size out of shaping Bc/8... is that right?
A.
Brian McGahan wrote:
> 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
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:47 ART