Yes, everything you say about serialization delay is true. And, yes it's
true that a Frame Relay network waits for the whole frame to arrive and
then transfers it to the destination local loop. Frame Relay switches are
store-and-forward devices.
Serialization delay is the time to output the bits in a frame from an
interface at the circuit speed. Your local router outputs the bits across
your local loop. That's the first case where serialization delay happens.
The bits end up in the Frame Relay "cloud." The Frame Relay switch on the
destination side of the cloud also outputs the bits at the rate specified
for the destination local loop. Serialization delay occurs here also.
Most books and calculation methods ignore the serialization delay of the
switches in the cloud and any intermediate routers. This is kind of silly,
but the reason is that there's no easy way to tell what devices and links
are in the cloud. (That's why it's called a cloud.)
In general, people don't worry about serialization delay with most
applications, including testing with ping. Serialization delay has become a
concern recently because of delay-sensitive applications such as voice and
video. The reason you need to care about serialization delay in those cases
is because it can take a long time to output the bits of a large frame onto
a slow circuit. A small, inpatient voice frame might be behind that large
frame, waiting to get output. Remember this is serial, that is, one bit at
a time............
So with voice and video applications, you need to think about the effect of
outputting a large FTP 1500-byte frame, for example, while a little
delay-sensitive 64-byte voice frame is waiting behind the large frame to
get its chance to be output.
To address this issue you can use fragmentation. The Frame Relay Forum now
has a bunch of optional standards for dividing up frames at the
data-link-layer. Depending on which option you use, these frame can remain
fragmented for the whole trip, including on output to the destination local
loop. These standards solve the problem of the small frame waiting behind
the large frame.
By the way, on high-speed circuits, serialization delay isn't an issue. The
large frames zip out so fast that the serialization delay is negligible. In
these cases, it's best not to do fragmentation.
One other by the way, serialization delay is not the same thing as
propagation delay. Propagation delay measures how much time it takes to get
across the network, (rather than how much time to get out the interface).
Propagation delay can be a major issue if you are going long distances. The
actual delay would depend on the type of cabling, whether there are
satellites or not, etc. But assuming no satellites and typical fiber-optic
cabling, it's something like six microseconds per kilometer or one
nanosecond per foot for metric-challenged people in the U.S. Don't ask me
why I remember these sorts of things! &;-)
Priscilla
At 02:45 PM 9/14/00, Kent wrote:
>Hi all,
>
>Could not rember from where I read the following:
>
>"
>--- For example, 64 kbps link = 8000 bytes/second.
>Suppose you have a 2000 byte packet.
>
>Then the serialization delay is 2000/8000
>seconds. That's 250 millseconds
>in one direction of transmission (from source to
>destination, excluding the
>return trip for a ping).
>
>For a frame relay network, you serialize once to
>get it into the frame relay
>network (over the local loop). That's 250 msec.
>You serialize it again to
>leave the network, over the destination local
>loop. That's another 250
>msec. That's a total of 500 msec in one
>direction.
>
>However, for leased line, you have 250 msec
>only-- once to get it to the
>destination. "
>
>My question is about the double delay of FR, it looks
>like the author believes that the FR network waits for
>the whole packet to arrive and then transfers it to
>the destination local loop, is this something true?
>I can not understand, if within CIR, why this happens.
>
>Thanks
>
>Kent
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Mail - Free email you can access from anywhere!
>http://mail.yahoo.com/
>
>**NOTE: New CCNA/CCDA List has been formed. For more information go to
>http://www.groupstudy.com/list/Associates.html
>_________________________________
>UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
>FAQ, list archives, and subscription info: http://www.groupstudy.com
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
________________________
Priscilla Oppenheimer
http://www.priscilla.com
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
