Communication and Packet Switching
Synchronisation 53 advantageous where the line spends much of its time in an ‘idle’ mode in which a string of
2.16 The problem of long lines — the need to observe the maximum line length
During the course of this chapter we have covered the fundamental manner in which data can be coded in binary code inbits and then transported across a telecommunications line. We
8Nowadays 32-bit databuses are commonplace and even more bits lead to even higher processing speeds.
The problem of long lines — the need to observe the maximum line length 63
Figure 2.26 Parallel and serial transmission.
have also howprotocols are necessary to set out an etiquette of communication. But before we go on to discuss how the protocols themselves work, it is worth considering the ‘physical’
constraints which protocol developers are up against: what they must consider and incorporate in their protocol designs. In particular, it is important to recognise the influence of the line length. The best way of conducting the communication, and thus the best type of protocol to use, depends greatly upon the line length.
For many data networks and protocols a maximum line length, bit rate and other parameters are specified (or is not specified, but is nonetheless implicit in the design of the protocol!). It is important to be aware of these limitations when using the particular type of interface, line or protocol. Here’s why.
Attenuation and distortion
One of the problems of long lines is the degradation caused by attenuation and distortion, and this largely determines the maximum allowed line and link lengths possible in a given network and using a given protocol. But in addition to attenuation and distortion, there are some far less obvious problems which also limit line length. These are caused by the ‘storage medium’ and ‘transient’ effects of a long line, as we shall see next.
The effect of propagation delays on how protocols function
The electrical pulses which represent the individualbitsin a data signal typically travel across a network at a speed of around 10 million metres per second (108 m/s). This is around one third of the speed of light. The delay (as compared to the speed of light) is caused by the various buffers and electronic components along the way. If we assume quite a modestbit
rateof 2 Mbit/s (2×106 bit/s) is used to convey a signal along a given transmission line, we can actually work out the length of each pulse!
Bit length=[speed in m/s]/[bit rate]=108/(2×106)=50 m
The first time I contemplated the length of abit in metres, I was surprised by the result. After all, one tends to assume when considering electrical circuits that the transmission is instant:
‘the light goes on as I flick the switch!’ But this is far from true when we are dealing with high speed communication lines! If our 2 Mbit/s line above is 1000 km long (quite possible within a nationwide network, never mind an international connection!), then there are actually 20 000 bits (or 2500 bytes) in transit on the line at any one time [1000 000 m/50 m]. Say
‘stop’ and you’ll still receive at least all the 20 000 bits already on their way! Actually many more: because the ‘stop’ message will take some time to get to the receiver (this message is itself in a queue of at least 20 000 bits heading in the other direction). 20 000 bits will be received before the ‘stop’ message is acted upon by the transmitter, by which time a further 20 000 bits are already on their way. So after saying ‘stop’ be prepared to receive a further 40 000 bits (5000 bytes).
For the 5000 bytes you need abufferunless of course this data is simply thrown away! But throw the data away at your peril! For if you throw it all away, you’ll have to ask for it to be sent again, once you’re ready to receive it. That will mean another 5000 bytes (of ‘idle line information’) for the dustbin — wasted while the message requesting the retransmission gets through to the other end. Plus, of course, the 5000 bytes will have to be sent again. That’s 10 000 bytes of information we didn’t need to send over the line! We’ll have to be careful about all this waste, if the maximum capacity of the line is to be used efficiently!
A similar flow control problem to that discussed above is illustrated as a signal flow diagram in Figure 2.27. Protocol interchanges are frequently illustrated in this manner, so it is worth becoming familiar with how to read the chart. The left-hand vertical line represents the ‘A-end’
of a point-to-point connection, the right hand vertical line the ‘B-end’. The top of each line represents the beginning of the illustrated time period, and the ‘time axis’ progresses towards the bottom of the page. The diagonal lines represent individual bits sent from one end of the line to the other. (The bits progress along the line from one side of the diagram to the other, while time elapses down the page — hence the diagonal line.)
At the beginning of the time period shown, a ‘request’ signal is generated at the A-end of the line, to request data to be returned by the B-end. Since the request message is more than one bit long, a certain amount of time expires (shown as TRon the diagram) to transmit all of the message onto the line. Once on the line, the message propagates along the line towards the B-end (represented by the diagonal lines for the ‘first’ and ‘last’ bits of the request message).
After a period TP(called thepropagation time), the first bit of the request reaches the B-end.
The final bit of the request arrives a short time, TR, later. Now the message can be interpreted by the B-end computer. We assume in Figure 2.27 that it reacts instantaneously and starts to send the first packet of the requested data. (Normally a further processing delay would be encountered here.)
Further diagonal lines represent the first and last bits of the returned data packet as they make their way back to the A-end. After a total elapsed time TCthe first packet of data has completely arrived at A.
The protocol shown in Figure 2.27 requires that the A-endacknowledgesreceipt of the first packet of data before the B-end is allowed to send the second packet. The acknowledgement of the first packet and the transmission of the second packet is shown in the diagram.
Now let us consider the relative efficiency of our usage of the line. The total duration of a
‘cycle’ of sending a request (or acknowledgement) and receiving a packet of data is TC, where:
TC=(TP+TR)+(TP+TD)=2 TP+TR+ TD
The problem of long lines — the need to observe the maximum line length 65
Figure 2.27 A protocol signal flow diagram.
The proportion of the time for which the two communication paths (A-to-B and B-to-A) are in use reflects the efficiency of usage of each:
Usage efficiency (A-to-B)=TR/TC=TR/(2 TP+TR+TD) Usage efficiency(B-to-A)=TD/TC=TD/(2 TP+TR+TD)
Let us assume that we keep our request message very short; we assume it can be transmitted onto the line instantly (e.g., because of a very high line bit rate). Then we set TR=0. This is usually a reasonable assumption. Now, when the line is very short we can also ignore the time required for an individual bit to propagate along the line, by setting TP=0. In this case, we discover that:
For very short lines:
Usage efficiency(A-to-B: request direction)=0%
Usage efficiency(B-to-A: data direction)=100%
No surprises here perhaps. Data is being downloaded nearly all the time (100% line usage B-to-A), and our acknowledgements are a help in making sure that the A-end is always ready to receive the next packet. All hunky dory! But look at what happens when the propagation time TPbecomes significant. In particular, let us return to our previous example of a 1000 km line of 2 Mbit/s bit rate, and assumepacket lengthsof 256 bytes (2048 bits). In this case TP= 106 m/[108m/s]=0.01 s andTD=2048 bits/2 000 000 bits/s=0.001 s. And what are the line usage efficiencies?
Example long line of 1000 km and 256 byte packet size:
Usage efficiency(A-to-B: request direction)=0%
Usage efficiency(B-to-A: data direction)=4.8%
What? 4.8% line usage efficiency! A shock perhaps? Let it be a warning to all communications programmers and protocol designers!Acknowledgementsused with short packet sizes can lead to very low line utilisation on long, high bit rate lines!
The effect of delays on ‘collision’ protocols
In someshared medium networks (e.g., radio networks and ethernet LAN networks), users are allowed to transmit signals onto themedium provided they first check that the medium is free (i.e., idle). In such networks, the protocol has to be able to deal with collisions of packets sent by different sources.
Because of the propagation delay incurred by the signal sent by a first transmitter, a second remote device may start transmitting on the already ‘busy’ line, unaware that the transmission of the first device has not yet reached it. The danger is in the length of the line! The longer the line, or the greater the size of theshared medium network (e.g., LAN — local area network), so the greater the chance of a collision. The more collisions that occur, the less efficient is the use of the medium.
If the network is too big, the bit rate is too high (making the pulses too short) or the line is too long for the protocol in use, then the efficiency of the network may drop dramatically!
MORAL:Know the limitations of the network and protocols in use.