Logout

Home Topic 3 Last Next

3.1.7

Explain why protocols are necessary.

 

Teaching Note:

Including data integrity, flow control, deadlock, congestion, error checking.

 

Sample Question:

sdfsdfsf

JSR Notes:

 

Images needed!

General Rational for the Existence of Protocols:

Protocols, in general, exist to provide standard ways of communicating and interacting. Recently I heard a funny piece by Lucy Calloway of the BBC World Service bemoaning the fact that there are not strict international protocols about greeting each other in a business situation. So for example at an international gathering, some will try to kiss others three times on the cheek, others will bow, others will shake hands, all of different durations of shaking, and so on, causing nervousness, misunderstanding, and wasted emotional engagement when each should be more worried about establishing the business relationship.

Protocols are needed in computer networks primarily because the networks are made up of devices and software made by many different companies. The only way to ensure compatibility among everything is to have common documents, i.e. protocol specifications, that stipulate things such as the format of the data to be sent, and the mechanics of how it is to be sent and received.

Protocols are the basis for solving many networking problems and issues such as:

 

Specific to the Teaching Note:

Note that, in fact, a great way to address this assessment statement is to list and explain what is stated in the Teaching Note:

So your answer for a, say, [2 marks] only, would be: "Protocols are necessary so as to assure data integrity, manage the flow of data, prevent congestion and deadlock, and supply an agreed upon way of error checking".

But if it were a question worth more than a few marks, or if any one of those was asked details of, here is each one tweaked out a bit:

 

Data Integrity- The "correctness" of information over its entire life-cycle, meaning what is sent is what is received. In fact, this is part of what error checking is for. Refer to the error checking section below - but the point is that the protocol needs to have ***some*** way of assuring data integrity. (When playing "telephone" as elementary students, there was not good data integrity with the passing on of the message by whispers from student to student!)

Flow Control - Protocols dictate the ways servers are able control the flow of traffic through a network, particularly the speed of transmission. This helps prevent a fast sender from overwhelming a slow receiver.

The good analogy here for controlling flow would be how traffic is controlled though a city. Some of the rules:

Flow of control is all about traffic. The same sorts of traffic issues cars and buses have in a city, data also has when moving around a network.

Congestion - when everything in a network slows down due to the amount of traffic going through particular paths. Typical effects include queuing delay, packet loss or the blocking of new connections.

Different protocols offer different approaches to reducing congestion. One approach for relieving congestion is to not allow data to be sent at exactly the same time. Rather the sending of pieces of a big file should be staggered. Another approach is to flush the network at certain points of congestion and request re-sending.

Congestion can also be relieved simply by re-directing network traffic to alternative routes which are not the shortest but which are relatively uncontested.

Analogies, as always can help here. Congestion of automobile traffic can be to stagger when workers start in and finish their day. In Canada, rather than work 9 to 5, government workers work 8:30 a.m. to 4:30 p.m. to relieve traffic congestion. And traffic is also the reason ISB starts each school so early and ends so early. Re-routing of truck/lorrie traffic around a city on a "ring road" is often done to relieve inner city congestion. Flushing automobile traffic in the middle of the day, though, is not an option!

You'll note that it's routers and switches will do the actual routing, but they do so based on what is possible as dictated by the network protocol.

Deadlock - this is when traffic on the network grinds to a halt, due to levels of traffic that the server cannot handle. One way a protocol can prevent deadlock is by requiring the network server to re-start when a certain threshold of traffic is crossed, there-by chucking everyone off - the Internet server at my last school would do this. So the protocol in fact prevents deadlock, and possible freezing of the server, just before it would happen, by restarting. "Gridlock" in the automotive traffic analogy which refers to a situation in which there is such a high level of traffic congestion that no car can move.

Note the related cyber attack strategy: DDOS (Distributed Denial Of Service attack) - When a lot of requests are sent to a network serve by many computers - often these computers are infected or controlled by the bad guy. If enough requests are sent, the server can freeze.

But deadlock across a network can also happen when both sender and receiver are waiting for the other to reply; if both devices are precisely following proper protocol this is not supposed to happen. Re-setting is the one most obvious "solution".

Error Checking - the protocol will dictate the use of some sort of error checking algorithm to help assure that what was sent is what was received. Common error checking algorithms include parity checking and check sums. (See below for more details.)

To reiterate, data integrity is the main concern of error checking, but other aspects of the session need to be checked for errors as well.

 

Do note that each network protocol will specify particular ways of working with all of these things, deadlock, error checking etc. So the protocol TCP/IP may use weighted check sums for ensuring data integrity, while another protocol, like UDP, does not; rather, it may use unweighted checksums to assure data integrity.


 

 

__________________________________________________

 

 

For this assessment statement YOU DO NOT HAVE TO KNOW THE FOLLOWING TECHNICAL DETAILS of error checking, but a general appreciation of the way they work would be good to have.

 

A Bit More Details on Error Checking

Error checking in network communication, in general, is the processes of checking to see if there was an error in transmission. Usually this will be because of some sort of electromagnetic interference, which causes a bit to be "flipped". So before it was sent, it was a 1, but upon arrival at its destination, it is a 0, or vice versa.

Parity Checking

Parity checking is a system in which the number of binary 0s or the number of binary 1s in message ("message", in the case of network activity is a packet) are calculated before the message is sent, and after it is received. That number should be exactly the same if no errors occurred during the transmission. If it is not the same, it means there (was at least one) error. So re-transmission is requested.

In the he case where a particular protocol uses Even Number of Zeros Parity Checking, the number of 0s in a packet are counted up, and if that number is odd, another 0 is added as the "parity bit" to make the total number of 0s even. And if the number of 0s is even, then it is kept even by adding a 1 as the parity bit. When the packet arrives at its destination, the number of 0s is added up, and if it's still even, than no error is assumed to have occurred, if it's odd, then an error must have happened during transmission, and re-transmission is demanded by the protocol.

Check Sums & Weighted Check Sums

Parity checking is not so sophisticated, and what happens if two bits get flipped?? An alternative approach is to use check sums. A check sum is some sort of value that is calculated using a specific formula before and after transmission. As with parity checking, that number should be exactly the same if the message was un-altered during transmission. A simple example is as follow: add up the ASCII decimal equivalents of all the characters in the message, and see if it is the same after transmission. In order to be able to keep a check sum to one byte, what you do is take the remainder of that value divided by 255, rather than the full number (which would be over 255 for all but the smallest messages.

Check Sum Example:

ABC: that's 65 + 66 + 67 = 198 % 255 = 198. So what is sent is ABC198

If received without an error, the recalculation is:

ABC: 65 + 66 + 67 = 198 % 255 = 198 (So check! it's the same; 198 == 198, so everything is assumed to have been transferred correctly.)


But in the case of it being sent with an error occurring, say the last 1 of the C is changed to a 0:
0100 0001 0100 0010 0100 0011 -----------> 0100 0001 0100 0010 0100 0010

So what is received is ABB198, and the check sum calculation goes:

ABB: 65 + 66 + 66 = 197 % 255 = 197 - ERROR, ERROR (because 197 != 198, the check sum before sending) RE-TRANSMIT!


Weighted Check Sum:

The problem with the check sum is that two letters could be transposed, and the sum would be the same, so for example ABC would yield 198, but so would BAC. Each letter is therefore weighted by multiplying its ASCII value by the number which represents its place in the message.

ABC: that's (1 x 65) + (2 * 66) + (3 * 67) = 398 % 255 = 143

BAC: that's (1 x 66) + (2 * 65) + (3 * 67) = 397 % 255 = 142, and 142 != 143, indicating the error in transmission.

 

Jose: What could cause bits to get flipped and other corruption of data in transmission: one example is magnetism or electromagnetism affecting the wire/wireless signal; another more esoteric example is what's termed a "single event upset" caused by cosmic particles. Seriously.

 

 

 

 

ADDITIONAL INFORMATION ONLY

JSR Notes - FORMER CURRICULUM - 6.4.4 Outline the need for protocols in packet switching.:

With this assessment statement, the emphasis is not so much on the protocols themselves as the need to have them in the first place.  So this is a **protocols** assessment statement more than it is a TCP/IP one.

Look through the text on 344 and 345 to remind yourself what TCP and IP are, and on which levels of the OSI (Open System Interconnection) model they are found.  And also remember that the OSI model is just that, a model.  To fully understand all of what makes TCP/IP work within the full context of networking would take a couple of advanced degrees.  And neither TCP nor IP necessarily fit perfectly into one of the seven layers of that model.  And that’s not the point.  The point is the ‘P’ in each of these, the protocol; the idea that however this networking is going to work, the computers on either side of the connection had better agree on the ways to proceed.

And in terms, then, of what is to be agreed with TCP, think of the postal analogy; the way in which these packets are to be transported, both sent and received, must be agreed on from both ends.  To take a simple, extreme case with the analogy, there would be no sense of sending a parcel air mail to a place with no airport.  And oh yeah, don’t forget that it is “Transmission” Control Protocol.  In other words what are the rules and regulations for the actual control of the transmission of the packets through the network.

And with the IP part of it, again think of the postal analogy.  This is the “inter-network” set of rules for how the packets will be addressed; the format of the “where they are coming from” and the “where they are going to”.  Does the postal code need to be included, and how many numbers and letters should it have.  Actually IP is pretty easy compared to all of the non-standard postal address configurations out there; it is simply four 8 bit numbers separated by points, from 0.0.0.0 all the way up to 255.255.255.255.  And remember the interesting fact that this makes for around 4 billion possible IP addresses (in IP version 4).

It would’t hurt to also remind you that Domain Name Servers (DNS servers) keep a list of all the IP addresses out there with their corresponding short-cut domain name.  johnrayworth.info, for example is actually the IP address 195.250.148.236.

But anyway, much of this is beyond the point of the assessment statement; in packet switching systems, such as the one used for the Internet, there are certain protocols that once chosen must be followed; certain ways to, among other things, transmit packets and address them.  Without agreement on and adherence to these rules, these protocols, networking, in this case, would not work.