RE: FRF.12

From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sat Jul 17 2004 - 18:32:32 GMT-3


Scott,

        The reason you need to fragment is to ensure that a single
packet (or packet fragment) takes no longer than one Bc to be dequeued
to the transmit ring of the interface and be transmitted. This means
that your fragment size should be at a maximum (typically just equal to)
Bc as expressed in bytes.

        For example, suppose that you are shaping to 768Kbps and have
both voice and data. To ensure that voice packets get minimum delay,
the size of Tc will be set to 10ms. These values result in the
following calculation:

map-class frame-relay FRTS
 frame-relay cir 768000
 frame-relay bc 7680

        Based on these values, the maximum amount of traffic that can be
dequeued in a single interval is 960 bytes (7680 bits / 8 bits per
byte). Therefore, if there is a packet in the output queue with a size
greater than 960 bytes the shaping algorithm will have to go into debt
from further intervals, and have to pay this debt back. In order to
avoid this, the maximum packet size must be adjusted to 960 bytes, hence
the fragment size.

HTH,

Brian McGahan, CCIE #8593
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
> Scott Savage
> Sent: Saturday, July 17, 2004 4:18 PM
> To: ccielab@groupstudy.com
> Subject: FRF.12
>
> I have searched and looked through a number of
> documents covering frame-relay fragmentation and have
> not been able to find a good answer to this question.
> What is the correct way of calculating the # of bytes
> for fragmentation? In all the examples I have seen,
> it appears that the value is set to Bc when it is
> small and relates to voice and the value tends to be a
> fairly small number like less than half of the
> interface MTU or else 1/8th of Bc if Bc is larger than
> the interface MTU. I have found no rhyme or reason to
> this, though. Is it user preference as long as the
> number isn't smaller than the framesize of the
> "realtime" traffic you're trying "realtime" traffic you're trying to
> reduce latency for
> or larger than Bc?
>
> I am assuming in the real world you are really only
> going to use fragmentation when you are running
> something like voice/video across a link smaller than
> 768K. But if a question comes along dealing with
> fragmentation and the Bc value is greater than 1500,
> then what is the right way to determine the
> fragmentation byte count or what are the right
> details/requirements to pay attention to that would
> help you arrive at an acceptable number?
>
> =====
> --
> Scott Savage
>
>



This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:11:57 GMT-3