What makes a protocol good?

  • Thread starter Richard McMahon
  • Start date
R

Thread Starter

Richard McMahon

We all know in our own minds what a good protocol is, but what are the factors that make protocols good.

For example (and without wishing to light too many fires)

Basic ethernet is a good protocol for LANs, well understood, lots of application, easily suited for its environment, can carry a number of
different transport and network protocols.

IP is a good network protocol for peer to peer communication

TCP is a good connection orientated protocol

and without the interaction of these three protocols at the t-profile I could not send this message. By contrast, modbus is a bad protocol to
try to send an email, but it is a good protocol when you want to control plant.

So what are the features necessary to make a protocol good?

Determinism is important for timely transmission, but difficult to handle on dynamically adaptive networks without some form of network configuration management.

Wide bandwidth is important for large traffic flows but does that imply narrow bandwidth is bad in general?

I don't want to start a flame war over 'my protocol is better than yours'; as far as I care, all of the implemented ones are as good as each other wrt their own fields of application.

My motivation for the question is the need to review an adapter to translate the a-profile to any t-profile. Knowing the factors that drive
the layers in the t-profile defines the behaviour of the adapter. The t-profile implementation cannot be faulted but I suspect that the choice of profile is sub-optimal.

Your thoughts on this matter are gratefully appreciated.

Richard

--
Richard McMahon | Tel.: +44 117 954 5160
Safety Systems Research Centre | FAX: +44 117 954 5208
University of Bristol |
 
P

Patrik Brander

I write I/O drivers and I wish this question were asked every time that I see a new protocol.
A good protocol must have some kind of flow control to assure that the data in the answer actually belongs to the question asked.

This could be done in two ways:
1) By a sequence counter in the question that is returned in the answer. If I get an out of synch answer I know that it is not the answer to my question.
2) By specifying a maximum answer time. If I just wait the answer time I know that I will get the correct answer or no answer at all.

Most protocols used today do not implement either of above.
 
R

Ralph Mackiewicz

You are not framing the question properly.

TCP is not a good connection oriented protocol. It is a good connection oriented TRANSPORT protocol. Like Modbus, TCP would also make a very poor email exchange protocol.

"Good" is a qualitative term the meaning of which is going to vary from person to person. To know what is "good" you have to define "what its supposed to do". What is good is going to vary widely from situation to situation. "What is a good transport protocol for internetworking over WANs and LANs where information is not time-
critical?" is a question that can be answered. "What is a good protocol?" is a question that can't be answered honestly without tons of provisos.

Also, you are misusing the term "peer-to-peer". TCP is also a peer-to-peer protocol. Any protocol of a specific layer that communicates with its peer layer in the remote node, and also allows that peer layer to talk to it in the same manner, is a "peer-to-peer" protocol. IP is more accurately described as a connectionless network layer protocol.

> My motivation for the question is the need to review an adapter to
> translate the a-profile to any t-profile. Knowing the factors that
> drive the layers in the t-profile defines the behaviour of the
> adapter. The t-profile implementation cannot be faulted but I suspect
> that the choice of profile is sub-optimal.

Perhaps this is a little cryptic but I don't see why you even have to answer the "good" question to review an adapter to translate *the* a-
profile to *any* t-profile. "Any" implies that whether the t-profile is "good" or not you still need to translate the a-profile to it. Is
"translate" the right word?

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R
> I write I/O drivers and I wish this question were asked every time that I
> see a new protocol.
> A good protocol must have some kind of flow control to assure that the
> data in the answer actually belongs to the question asked.

Usually resolved by signature (slave reply includes slave address and function code and/or address etc.)

> This could be done in two ways:
> 1) By a sequence counter in the question that is returned in the answer.
> If I get an out of synch answer I know that it is not the answer to my
> question.

TCP has packet numbers, everybody else just adds there own when needed;-)
(not actually needed that often).

TCP needs this because timeouts are necessarily long for WAN protocols, and it is desired to send more than one packet down the pipe at a time.

> 2) By specifying a maximum answer time. If I just wait the answer time I
> know that I will get the correct answer or no answer at all.

Most 485 Mster slave protocols such as MODBUS and all those ad hoc proprietry ones such as OMRON use, in effect, timeouts. When the master has made a request, the bus is idle until the slave replies, some formalise the timeout but in many cases it is inherent as slaves will always reply within a certain time (i.e. the protocol does not define it but the device does).

In other sorts of protocols it would be superfluous because of thier nature.

What I hate is the obsession with MODBUS RTU, the ASCII is easier to handle (much easier at the PC end), more robust, and easier to test. Takes more bandwidth but not as much as some people seem to think.

> Most protocols used today do not implement either of above.

Name some........
 
R
Ralph Mackiewicz wrote:

> > Basic ethernet is a good protocol for LANs, well understood, lots of
> > application, easily suited for its environment, can carry a number of
> > different transport and network protocols.

Is it? Would be nice if LAN's could also carry synchronous data (phones, video, and perhaps DP) round the network.

> > IP is a good network protocol for peer to peer communication

IP is a good WAN protocol.

> > TCP is a good connection orientated protocol

Good for carrying data streams over WANS

> > and without the interaction of these three protocols at the t-profile
> > I could not send this message. By contrast, modbus is a bad protocol
> > to try to send an email, but it is a good protocol when you want to
> > control plant.

MODBUS is not much good at anything, but it is there;-)

It is a typical implementation of a simple master/slave protocol, the sort that is IMHO ideal for exchanging data with field devices on a large scale (close coupled small scale should look to DP or CAN). But let us not be eluded, the RTU protocol is an unecessary pig for implementing at the PC end, the protocol is orientated around control a specific ranges of
PLC, and hence the function codes become a bit of a joke. Also, the RTU CRC calculation is awkward to implement in e.g. ladder logic on strange
devices. Far better the ASCII mod ein this respect, but why not just throw out the function codes and have one big address space that the
device can virtually map. Then it also lacks a standard way for templating or profiling the data in the reply.

> You are not framing the question properly.
>
> TCP is not a good connection oriented protocol. It is a good
> connection oriented TRANSPORT protocol. Like Modbus, TCP would also
> make a very poor email exchange protocol.

I thought IP was the transport and TCP was for managing fixed streams of data.

> "What is a good transport protocol for
> internetworking over WANs and LANs where information is not time-
> critical?" is a question that can be answered. "What is a good
> protocol?" is a question that can't be answered honestly without tons
> of provisos.

LAN and WAN requirements are very different.

> Also, you are misusing the term "peer-to-peer". TCP is also a peer-to-
> peer protocol. Any protocol of a specific layer that communicates
> with its peer layer in the remote node, and also allows that peer
> layer to talk to it in the same manner, is a "peer-to-peer" protocol.
> IP is more accurately described as a connectionless network layer
> protocol.

that is one interpretation, but peer-to-peer is a phrase mostly used at a system description level, i.e. clients or slaves talk to each other
without going through (or being controlled by) a master or server.
 
R

Richard McMahon

Patrik Brander wrote:

> This could be done in two ways:
> 1) By a sequence counter in the question that is returned in the
> answer. If I get an out of synch answer I know that it is not the
> answer to my question.
> 2) By specifying a maximum answer time. If I just wait the answer time > I know that I will get the correct answer or no answer at all.

You could also send a question and receive the question with the answer.
Advantage: it is explicit and you get the roundtrip time independent of the network time 'automagically' including sampling times.
Disadvantage: bandwidth hungry

So the protocol needs some form of unique reference in the header to the message, for those messages requiring answers to specific questions.
Not required for messages like "What is the current time?". Tanenbaum describes this and your next point in his stuff on distributed systems.

Traceability and sequence are good things when answers are required.

Which leads to the second point, what is the maximum time and how do I know if it is exceeded? For time critical systems IEC61508 requires you
to do some modelling and I am obviously thinking of stuff affecting SILs at this point. This will determine acceptable timeouts. Wide bandwidth
will speed up message transmission in congested areas but costly.

Again determinism appears to be an important player but does this mean probabilisitic protocols are second class citizens?

Richard
--
Richard McMahon | Tel.: +44 117 954 5160
Safety Systems Research Centre | FAX: +44 117 954 5208
University of Bristol |
 
R

Richard McMahon

Everyone,

I apologize now for not framing the details more specifically. Perhaps I should have stated from the outset that of all the myriad of inter
networking protocols, I am only concerned with the lower four. All I am concerned with is transport and message passing.

Modbus and TCP can both transport data, I accept that, but TCP can transport bigger chunks of data in one go unlike modbus. That is the point I was trying to make.

Yes, "good" and "what it is supposed" to do are historically confused. Function can be distilled up to higher levels where the concepts are more general. I would suggest that the factors that make a protocol good are scalability, ease of learning, adaptability. A good protocol on the
other hand allows for efficient transport over restricted or degraded media, is easily available and so on. Perhaps there is room for the
suggestion of a better term to describe protocol fitness.

Peer to peer; I was referring to the fact that IP actual negotiates the network side of the transaction as opposed to TCP which carries the
data, to all intents, irrespective of the destination despite the presence of destination address in the header field. I know that the V
diagrams frequently show a 1 to 1 relationship at this point, but I personally think this should be tunnelled through the network layer to show a dependency on (unspecified) lower level services.

Translate is what I mean when referring to an adapter. From GOF

"Adapter is retrofitted to make unrelated classes work together."

"Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one."

That is, it provides a translated view of each profile on either side of the interface of the other profile regardless of the suitability of that profile. It must depend on one of the profiles and in this case it is the lower, t-profile. There will be a corresponding adapter above written specifically for each application level service.

The quotes are from GOF, copied off:

http://rampages.onramp.net/~huston/dp/adapter.html

Sorry for the confusion and misunderstanding created by my first message.
 
L
Here we go again - light-hearted skepticism from an ex-Map/Top'r ;->

The bottom line ALWAYS comes back to what do you need to do. No one answer fits all & such dichotomies tend to be at the heart of all "standard" network efforts.

Example, the needs of a protocol to send 2 bytes of data every 100msec is VERY different from the need for a 1 shot send of 1,000,000,000 bytes of
data never to be repeated. It's the little-fast-often guys fighting with the big-reliable-seldom guys. A similar dichotomy exists between the LAN/WAN issue - what works good on a WAN is wasteful on a LAN - what is optimized & sleek for a LAN lacks features needed for WAN.

Given the state of TCP/IP, arguments at that low level (UDP verse TCP verse something new) are little more than mental gymnastics.

Instead I'll jump up to the user app layers where the REAL important works needs to be done.

Modbus/TCP is a "wonderful" protocol by some measures because with an existing TCP/IP stack you can do a solid Modbus/TCP interface in an
afternoon. True, there are many things (object oriented behavior or auto-browse in OPC) which are near impossible to do in Modbus/TCP, but if
low-cost, fast-time-to-market, and easy multi-vendor interface are your goal, Modbus/TCP is a charm.

Alternatively something like Ethernet/Ip enables a whole new level of functionality with object class & instance, service codes etc. The idea of a
"browse" is a natural. Yet Ethernet/Ip will either take you 2-3 months to really figure out & implement (or you pay someone else to "help"), plus many existing Ethernet/IP devices have a few more proprietary "Vendor Class Objects" than they should. But again, if your goal is modern
producer/consumer and/or object oriented design Ethernet/IP is a much better way to go than trying to FORCE Modbus/TCP to support objects.

What about IDA/NDDS? They ignore the lower level protocols "as a detail" and instead concentrate on a reliable data service abstracted largely
independently from the network underneath

regards

Lynn August Linse, Senior Product Application Engineer
15353 Barranca Parkway, Lantronix Inc, Irvine CA 92618
[email protected] www.lantronix.com
Tel: (949)300-6337 Fax: (949)453-7132
 
R

Ralph Mackiewicz

> > > Basic ethernet is a good protocol for LANs, well understood, lots
> > > of application, easily suited for its environment, can carry a
> > > number of different transport and network protocols.
>
> Is it? Would be nice if LAN's could also carry synchronous data
> (phones, video, and perhaps DP) round the network.

There are IETF protocols specified in RFCs for transporting synchronous data. Go to: ftp://ftp.isi.edu/in-notes/ and look at the RFCs ending in 00. These are summaries of the RFCs that are standards. You will find several such protocols there.

> > TCP is not a good connection oriented protocol. It is a good
> > connection oriented TRANSPORT protocol. Like Modbus, TCP would also
> > make a very poor email exchange protocol.
>
> I thought IP was the transport and TCP was for managing fixed streams
> of data.

IP is the network protocol. It does not have error retransmission and reassembly functions like TCP which is the transport protocol. TCP is a
streams based transport protocol originally designed to handle stream oriented data like telnet. However, TCP is widely used to carry packet based protocols as well. This does create some inefficiencies as have been discussed in previous posts (e.g. many TCP implementations use timers to determine the end of a stream). However, no one seems terribly interested in the alternative transports that are available because the Internet is not based on them.

> > "What is a good transport protocol for
> > internetworking over WANs and LANs where information is not time-
> > critical?" is a question that can be answered. "What is a good
> > protocol?" is a question that can't be answered honestly without
> > tons of provisos.
>
> LAN and WAN requirements are very different.

True, but the transport protocol requirements for the two are very similiar. On the other hand, the network, data link, and physical layer requirements for WAN versus LAN are very different from each other.

> > Also, you are misusing the term "peer-to-peer". TCP is also a
> > peer-to- peer protocol. Any protocol of a specific layer that
> > communicates with its peer layer in the remote node, and also allows that
> > peer layer to talk to it in the same manner, is a "peer-to-peer"
> > protocol. IP is more accurately described as a connectionless network
> > layer protocol.
>
> that is one interpretation, but peer-to-peer is a phrase mostly used
> at a system description level, i.e. clients or slaves talk to each
> other without going through (or being controlled by) a master or
> server.

That is the definition of the word "peer", not an interpretation. Webster's dictionary defines peer as "one that is of equal standing with
another". I can't see how you can apply that definition to a master/slave system. Systems that are interconnected through a server are usually
referred to as client/server systems. "Client" is not analogous to "slave" and "master" is not analogous to server. Master/Slave is a communications system where all communications activity is initiated by the master (like
Profibus DP and Modbus serial). Client/Server systems allow clients to initiate communications to a server but the relationship between them is
not equal (like Novell and other file server based NOS). A peer-to-peer system is where both sides can initiate communications and both sides can behave as both a client and a server to each other (like the file sharing software built-in to Win98). In a peer-to-peer system it can be helpful to use the terms "calling" and "called" to indicate which side initiated the original association (calling) between the 2 nodes versus the side that responds to the original initiation (called). However, once the association is established either side can be a client or server to the other on a given transaction. In most networking schemes in use today (MS, Novell, TCP/IP) all the protocols below the application layer are peer-to-peer. The application layer is usually what restricts functions to a
client/server relationship.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
Top