Transmission (Store and Forward) Delay

Question Detail: 

The Kurose & Ross book uses "store-and-forward delay" as a synonym for the transmission delay of a packet over a network link.

As a newcomer to computer networks, it isn't immediately obvious to me how these two terms are synonymous. My current understanding is that if not for the store-and-forward behavior of packet switches, the transmission delay of a link would be negligible as it would be pipelined with the propagation delay of the previous link; i.e. as the bits propagate across Link A, they are transmitted and stream into Link B. However, due to store-and-forward, no bits are transmitted onto Link B before all the bits have crossed Link A, and hence, we need to add the transmission delay of Link B.

Is this correct?

Asked By : Isaac Kleinman
Best Answer from StackOverflow

Question Source : http://cs.stackexchange.com/questions/13501

Answered By : Patrick87

Transmission delay refers to the time it takes to push the bits of data onto the link, and is given by $L/R$, where $L$ is the amount of data and $R$ is the rate. Propagation delay refers to the time it takes for a bit, once on the link, to reach the destination. The propagation delay is given by $d/s$, where $d$ is the distance the data must travel and $s$ is the speed at which data travels through the medium. Other kinds of delay include the processing and queuing delays.

Store-and-forward refers to the fact that most routers work by receiving entire chunks of data before forwarding any part of the chunk. Some store-and-forward is of course necessary, supposing that the forwarding information is contained in the body of the message, as is the case in any packet-switched system. Store and forward can actually be avoided, for the most part, in circuit-switched networks, or by using something referred to as wormhole routing. However, for the most part, entire messages are received from the transmitting protocol (link-layer for switches and network-layer for routers) before transmission continues, so that you can do things like verifying checksums/CRCs, etc.

Your understanding looks basically sound. If it weren't for store-and-forward, and neglecting both processing and queuing delays, the end-to-end delay would be the sum of propagation delays plus $L/min\{R\}$, where $min\{R\}$ is the slowest transmission rate of any link along the path.

Consider the following example. You want to send a dozen eggs to your friend in the next room. There is a large conveyor belt between you and your friend and it moves any items you place onto it at 1 m/s. Your friend is 10 m away, and so the propagation delay is 10 s. Using both hands, you are able to take eggs from the carton and place them on the belt at a rate of 2 eggs per second. The transmission delay is 6 seconds. Your friend finishes receiving all the eggs exactly 6 + 10 seconds after you began transmitting eggs.

Even though the propagation delay is larger than the transmission delay, you must still account for the transmission delay. To see what I say at the end of my answer, consider sending the dozen eggs over two conveyor belts. Assume the guy moving eggs between conveyor belts can move them at a rate of 1.5 eggs/second (and that he has an unbounded wait queue for arriving eggs). If we store and forward, the guy will let all 12 eggs fall into his queue (a basket, maybe) and then put them on the next belt; his transmission delay is added to the total. If he doesn't store and forward, and moves eggs along as they become available, assuming the same propagation delay on both belts... (1) I put the 12th egg on the first belt at t=6 ; the last egg arrives to him at t=16 ; he has put 9 eggs on the second belt and now has 3 in his basket; it takes him 2 more seconds to finish putting these on the second belt, so the last egg makes it onto the second belt at t=18 ; and the last egg arrives at the destination at t=28 . We see that this is the sum of propagation delays plus the larger transmission delay, as claimed. Using store-and-forward, the delay is 34 s.

No comments

Powered by Blogger.