From: Ahmed Ossama (ahmed_ossama@rayatelecom.net)
Date: Tue Aug 09 2005 - 06:43:07 GMT-3
Yep got that,
Thanks a lot for your clarification brian
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: Monday, August 08, 2005 9:03 PM
To: Ahmed Ossama; ccielab@groupstudy.com
Subject: RE: FRTS and serialization
Ahmed,
If the packet size is larger than the byte increment (Bc * 8)
then it will take more than one Tc to encapsulate the packet. If the
byte increment is less than the MTU of the interface you should
configure fragmentation to ensure that the serialization delay for a
packet fragment does not exceed one Tc. This allows you to interleave
real-time packets between delay insensitive fragmented traffic such as
FTP.
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
> Ahmed Ossama
> Sent: Monday, August 08, 2005 6:42 AM
> To: ccielab@groupstudy.com
> Subject: FRTS and serialization
>
> Dear All,
>
> I need to know exactly the effect of making the TC the smallest value
(
> 10 ms ), I read that it helps to alleviate the serialization problem.
> What I want to understand if a large FTP packet is transferred and we
> set TC to a minimum 10 ms does this will prevent the packet from being
> transferred over several TC intervals, all I want to say is that the
BW
> will be overwhelmed by this packet even if we make the TC small.
>
> We must make fragmentation on the frame-relay class map in order to
> prevent that.
>
>
>
> I don't know why we set the TC value small and what is the benefits of
> that
>
>
>
> Regarding the fragmentation am I right for this point ?
>
>
>
> Best wishes,
>
>
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3