Re: Protocol Definition

[John Day <[e-mail]>]

At 15:29 +0900 2012/01/09, Martin Sustrik wrote:
>On 01/09/2012 01:35 PM, John Day wrote:
>>At 23:38 +0100 2012/01/08, Martin Sustrik wrote:
>>>On 08/01/12 13:00, John Day wrote:
>>>
>>>>You are also correct that strictly speaking the words "protocol" and
>>>>"algorithm" are probably the same.
>>>
>>>That is an interesting point.
>>>
>>>What I encounter often is the belief that protocol is just
>>>"description of bytes on the wire". People often forget about the
>>>stuff that cannot be seen on the wire (e.g. TCP state machine).
>>
>>This is clearly not the case and has never been the case.
>>
>>In fact, "bytes on the wire" is probably the smallest part of a protocol
>>specification. A protocol specification must specify what to do with the
>>"bytes on the wire/"
>>
>>The next time someone suggests that merely ask, what do you do with the
>>bytes on the wire? Where is that specified? The action to be taken when
>>a message arrives is all there is.
>>
>>There was once a group who thought that names of the fields in their
>>protocol was sufficient to specify what was to be done with them. I
>>pointed out the them that a legal value of every field in their protocol
>>was the letter "Z". They objected to this quite strenuously, but I asked
>>to show me where it said this was not the case. ;-)
>>
>>Anyone who says that merely specifying the format of messages (bytes on
>>the wire, as you say) constitutes a protocol specification is clearly
>>not competent to be making such pronouncements.
>
>Agreed. However, consider following problem: Imagine there's a 
>specification that doesn't define any new wire formats, only 
>specific ways to handle existing messages (UDP packets, SCTP 
>messages or whatever). Is it still eligible to become an IETF 
>protocol?

Two problems here:  1)  The scope of the IETF has nothing to do with 
the original question of "what is a protocol?"  For that you will 
have to consult the rules of the IETF.

2)  The specifications of UDP, SCTP, etc provide the full and 
complete specification of their messages.  So you must be defining 
something else, or you are proposing modifications to these 
protocols, so you should be working with their groups.  In the case 
of UDP, I highly doubt this.

Sounds to me that you are working with the very old phone company 
"beads-on-a-string" model rather than the more modern layered model. 
But then that seems to be fairly prevalent in the IETF.

>
>>>The area I work in has little or no special "bytes on wire" (simple
>>>message-based underlying transport is sufficient) but a lot of
>>>algorithmic stuff. Consequently, it was often dismissed as not being a
>>>protocol.
>>
>>"has little or no special "bytes on wire" (simple message-based
>>underlying transport is sufficient)" I have no clue what this phrase
>>could possibly mean. If you are passing messages, there must be "bytes
>>on the wire" otherwise, the messages have not been exchanged.
>
>What I am working on is business messaging (a.k.a. message-oriented 
>middleware). In lot of cases it works ok with existing message 
>formats (e.g. UDP packets, PGM APDUs, SCTP messages etc.) and 
>doesn't require any additional data to be passed on the wire.

This makes no sense whatsoever.  UDP and SCTP messages change the 
state (not much in the case of UDP) of their protocol machines, etc. 
If what you say is true, i.e. doesn't require any additional data to 
be passed on the wire, then I can guarantee that your "business 
messaging" does nothing.

UDP and SCTP messages are consumed by those protocols machines.

>
>What the specification focuses on are things like: If TCP is used to 
>form a one-to-many message distribution tree, how should we handle 
>TCP flowcontrol/pushback in such a way that a single slow receiver 
>doesn't block the whole message distribution tree? Or: How to 
>receive messages from multiple sources without allowing one sender 
>to starve out the receiver and thus block the other senders (some 
>form of fair-queueing is needed)? Etc.

These are local matters unless feedback is used.  In which case there 
is a protocol.  Having worked through these issues years ago, it 
sound to me like you don't have a clear picture of the model.

Take care,
John Day

>Martin