Subject: Protocol Definition

From: Kaushal Shriyan <[email-masked]>
Date: Wed, 4 Jan 2012 07:23:24 +0530

Hi,

Can someone please explain me the term "Protocol". Does it also mean it has
some software code underlying beneath it. Please help me understand.

Regards,

Kaushal

---

From: Ole Jacobsen <[email-masked]>
Date: Tue, 3 Jan 2012 17:59:22 -0800 (PST)

In very simple terms: A protocol is a set of rules for interaction. In 
this case the interaction is between computers. This can involve both 
hardware and software and protocols define the interactions as well as 
the "formats" (bits on the wire etc).

For a much more comprehensive definition, see:

http://en.wikipedia.org/wiki/Communications_protocol

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj
Skype: organdemo

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 4 Jan 2012 10:07:20 +0000

A protocol is to communications what an algorithm is to computation.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Jacobsen
Sent: Wednesday, January 04, 2012 03:59
To: Kaushal Shriyan
Cc: [email-masked]
Subject: Re: Protocol Definition

Ole

Ole J. Jacobsen

> some software code underlying beneath it. Please help me understand.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Jan 2012 06:48:54 -0800

> A protocol is to communications what an algorithm is to computation.

The mantra that I was taught many years ago was that a process is a program in 
execution.  A program is the instructions.  That seems compatible with the above 
observations.

(One can quibble about the difference between algorithm and program.  An 
algorithm is a component of a program.  The distinction is relevant here because 
a protocol is typically a complete mechanism rather than being a component of 
the mechanisms.  On the other hand, an entire Internet service might comprise 
multiple protocols.)

My question is:

      If protocol corresponds with program or algorithm, then what is the 
communications term that corresponds to process?

      It's tempting to say "port number", but that doesn't seem very satisfying.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave Cridland <[email-masked]>
Date: Thu, 05 Jan 2012 15:01:57 +0000

On Thu Jan  5 14:48:54 2012, Dave CROCKER wrote:
>      If protocol corresponds with program or algorithm, then what  
> is the communications term that corresponds to process?
> 

"Session"?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Jan 2012 08:50:23 -0800

>> (One can quibble about the difference between algorithm and
>> program.  An algorithm is a component of a program.
...
> Or an algorithm is an abstraction (usually mathematical as
> distinct from some other sort of specification)  and the program
> (or part of it) is a specific realization of that abstraction.

As a discussion detached from utility in the IETF, that view has academic merit, 
of course.

In terms of practical IETF discussions -- and for the comparative purposes this 
thread was developing -- I am used to the view that a program typically contains 
multiple algorithms and therefore performs a larger and integrated /set/ of 
activities (functions).

Note that Wikipedia nicely correlates algorithm with function, which largely 
matches the "component of" view that I suggested.

> The difference between that distinction and the one you make is
> that we have a long history of correct algorithms and incorrect
> or inadequate implementations.

And indeed the tendency to confuse constructs /within/ network architecture with 
the distinction /between/ network architecture and software implementation is 
quite common.

For the IETF, we typically do not focus on implementation correctness, except to 
the extent that a pattern of implementation problems might affect architectural 
choices to improve simplicity.

I've assumed that this thread on the IETF list ought to focus on uses of the 
terms that aid IETF work...

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Jan 2012 10:13:23 -0500

--On Thursday, January 05, 2012 06:48 -0800 Dave CROCKER
<[email-masked]> wrote:

> program.  An algorithm is a component of a program.  The
> distinction is relevant here because a protocol is typically a
> complete mechanism rather than being a component of the
> mechanisms.  On the other hand, an entire Internet service
> might comprise multiple protocols.)

   john

---

From: todd glassey <[email-masked]>
Date: Thu, 05 Jan 2012 09:06:40 -0800

On 1/5/2012 6:48 AM, Dave CROCKER wrote:
> The mantra that I was taught many years ago was that a process is a
> program in execution.  A program is the instructions.  That seems
> compatible with the above observations.
> 
> algorithm is a component of a program.  

The program is the code-based implementation of the alg?

 The distinction is relevant here
> because a protocol is typically a complete mechanism rather than being a
> component of the mechanisms.  

I.e. "A complete method of doing something"...

> On the other hand, an entire Internet
> service might comprise multiple protocols.)

Yes but the Service then is a superset of the Protocols themselves in
that instance as opposed to a single service.
> communications term that corresponds to process?

I think Event Streams seems to be the best way of categorizing those
happenings (or events).

>      It's tempting to say "port number", but that doesn't seem very

No, you are right here and it's because there may be no ports/sockets in
the protocol as in IPC for instance.

-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Jan 2012 09:13:45 -0800

>> It's tempting to say "port number", but that doesn't seem very satisfying.

That's an appealing suggestion.  It is based on a 'state' existing between the 
two end points and it is above transport (so we don't have to worry about tcp vs 
udp vs...).

On the other hand, isn't a session able to have more than one "connection" and, 
therefore, possibly be running more than one protocol?

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Thu, 05 Jan 2012 09:54:00 -0800

On 1/5/12 9:13 AM, Dave CROCKER wrote:
> >> If protocol corresponds with program or algorithm, then what is
> >> the communications term that corresponds to process?
> >>
>  That's an appealing suggestion. It is based on a 'state' existing
>  between the two end points and it is above transport (so we don't
>  have to worry about tcp vs udp vs...).
>
>  On the other hand, isn't a session able to have more than one
>  "connection" and, therefore, possibly be running more than one
>  protocol?

Dave,

Agreed.  A multiple stream protocol aggregates multiple endpoints into 
an Association where each then signals supported protocols.  Within each 
protocol, various algorithms are applied, often in phases such as Bind, 
Listen, Accept, Connect, Close, Shutdown, SendMsg, RecvMsg, 
GetPeerName.  An algorithm might be expressed using computer languages 
that incorporate elaborate mathematical models, such as simple hash 
functions used to validate packets.  One of the protocols supported is 
SDP Session Description Protocol that carries media over the multiple 
streams.  This provides for Sessions, Associations and Connections.

See:
http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-07#page-3

-Doug

---

From: Dave Cridland <[email-masked]>
Date: Thu, 05 Jan 2012 21:41:49 +0000

On Thu Jan  5 17:54:00 2012, Douglas Otis wrote:
> Agreed.  A multiple stream protocol aggregates multiple endpoints  
> into an Association where each then signals supported protocols.   
> Within each protocol, various algorithms are applied, often in  
> phases such as Bind, Listen, Accept, Connect, Close, Shutdown,  
> SendMsg, RecvMsg, GetPeerName.  An algorithm might be expressed  
> using computer languages that incorporate elaborate mathematical  
> models, such as simple hash functions used to validate packets.   
> One of the protocols supported is SDP Session Description Protocol  
> that carries media over the multiple streams.  This provides for  
> Sessions, Associations and Connections.

As you say, algorithms can be expressed in terms of other algorithms.

And yes, "session" is certainly an overloaded term (as is protocol,  
mind, which can be used for extensions and "sub protocols" as well).  
But I think it's the best we have, and I think it's commonly used  
anyway. Association, to my mind, means a transport layer connection,  
hence it's usage in SNMP and other OSI-related things.

Session isn't much less damaged, as a term, I admit, but it is in  
common usage. And like algorithms, and protocols, you can open up a  
session to find other sessions inside.

So for example a session of XMPP may include:

- Multiple sequential XMPP-carrying TCP sessions ("connections"),  
which are considered a single "Session" by dint of using XEP-0198 (An  
"XMPP Extension Protocol") to glue them together.

- Jingle negotiations, which speak an XML adaptation of SDP,  
negotiating RTP sessions for A/V.

Now, it's entirely fair to say that your XMPP session may include  
multiple TCP sessions, and each TCP session speaking XMPP may use  
Jingle sessions to negotiate multiple media sessions. We have lots of  
terms that require qualification to be of any use, and "session",  
"protocol", and even "connection" all need this.

Dave.

(Sent over a mail session using both IMAP and ESMTP sessions in  
concert with an ACAP session).
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 19:21:58 -0300

> communications term that corresponds to process?

"Protocol Machine". or "Protocol Instance".

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Jan 2012 19:03:26 -0800

On 1/5/2012 1:41 PM, Dave Cridland wrote:
> Association, to my mind, means a transport layer connection, hence it's usage in
> SNMP and other OSI-related things.
>
> Session isn't much less damaged, as a term, I admit, but it is in common usage.
> And like algorithms, and protocols, you can open up a session to find other
> sessions inside.

Actually, my recollection is that 'association' was an application-level 
construct from OSI.

But I came to the same conclusion as you:  "session" is an established term in 
IETF parlance and has the basic reality of describing a protocol in operation 
between two (or more?) hosts/endsystems/endpoints/...

Does this resonate with others?

d/
-- 

   Dave Crocker

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Jan 2012 22:10:34 -0500

I suspect that the "correct" choices depends upon how you look at the 
analogy.
What seemed to me the closest analog to "process" would be the actual 
messages on the wires.

yours,
Joel

On 1/5/2012 10:03 PM, Dave CROCKER wrote:
>> common usage.
> But I came to the same conclusion as you: "session" is an established
> term in IETF parlance and has the basic reality of describing a protocol
> in operation between two (or more?) hosts/endsystems/endpoints/...
>

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Jan 2012 19:17:13 -0800

On 1/5/2012 7:10 PM, Joel M. Halpern wrote:
> I suspect that the "correct" choices depends upon how you look at the analogy.
> What seemed to me the closest analog to "process" would be the actual messages
> on the wires.

Nah.  A message on the wire is a single unit in an activity.  And taken on its 
own, in the host or on the wire, it's actually static.

It isn't the activity.  A process is an activity.  The challenge is a term for 
the /flow/ of messages.

It would be nice if it were a single word.

d/
-- 

   Dave Crocker

---

From: Yaakov Stein <[email-masked]>
Date: Sat, 7 Jan 2012 20:11:02 +0000

X.200 - ITU's version of the OSI model - defines an "association" as peering at any layer of the OSI stack.
Thus an association at layer 3 is a pair of IP addresses, while an association at layer 4 is a pair of socket IDs.
If the association is requested then it becomes a "connection".
A "session" is an association at layer 5.

A process in computation is defined as an entity that is independent 
in the sense that it can request and own resources (e.g., CPU time and memory).
Many processes can exist side by side, and can even communicate via IPC,
but processes do not have a hierarchy such as we have in communications.
The closest thing is the fact that processes can own tasks or threads as sub-entities
(tasks are not indendent - their memory and CPU time are taken from their father process).

Just as an association runs protocols at different layers, a single process frequently runs multiple algorithms.
But these algorithms are usually not layered.

A protocol between two entities often involves algorithms on both sides,
but an association does not necessarily link two processes on the communicating sides.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Friday, January 06, 2012 05:03
To: Dave Cridland
Cc: IETF-Discussion
Subject: Re: Protocol Definition

d/
-- 

   Dave Crocker

---

From: John Day <[email-masked]>
Date: Sat, 7 Jan 2012 16:00:14 -0500

At 20:11 +0000 2012/01/07, Yaakov Stein wrote:
>Thus an association at layer 3 is a pair of IP addresses, while an 
>association at layer 4 is a pair of socket IDs.

Not quite.  The identification is only part of what constitutes an 
association.  The situation at layer 3 is a bit more complex since 
there are potentially 3 data transfer protocols in Layer 3 depending 
on requirements, configuration, and technology:  SNAC, SNDC, and 
SNIC.  An assoication consists of the shared state for an instance of 
communication among (N)-entities. (see below).

It is true it is a general concept that appears in all layers. I 
believe I wrote that definition.  (X.200 and ISO 7498 are the same 
document. There is not an ISO version and an ITU version.)  It was 
inserted rather late because of the requirements for the Application 
Layer Structure document (ISO 9545, X.207)

>If the association is requested then it becomes a "connection".

No, this is not true.  The association is only the shared state 
between the protocol entities.  As I indicated in the previous email. 
A "connection" is more encompassing.  It includes shared state from 
the corresponding (N+1)-entities, the (N)-service-access-points, and 
the (N)-entities. (The role of (N)-SAPs in the OSI Reference Model is 
another major flaw in the model.)

>A "session" is an association at layer 5.

No, I believe they would have said that a "session" was a connection 
at layer 5.  (However, by October 1983, it was recognized that the 
upper 3 layers were a fiction and the protocol specifications were 
"adjusted" so they could be implemented as a single state machine. 
(This became the OSI clueless test.  Anyone who built the upper 3 
layers as 3 separate layers was clearly clueless.)

>(tasks are not indendent - their memory and CPU time are taken from 

If you are looking at X.200.  You might also look at the definitions 
(N)-entity-type and (N)-entity-invocation.

>
>Just as an association runs protocols at different layers, a single 
>process frequently runs multiple algorithms.

Associations don't run anything.  An (N)-association is the locus of 
shared state between two (N)-entities.  Actually, 
(N)-entity-invocations.  As I implied in my last email, the 
definition of "association" should have been the definition of 
"connection" or "flow."  An association corresponded to the shared 
state of a single flow or connection in a single layer.

The reason both were needed because the PTTs forced a wrong 
definition of connection in the very early going.  The definition of 
connection was set by 1978.  The definition of association did not 
appear until later.  I would have to check, but I don't think 
association is the 1984 version of the Reference Model but only the 
1994 edition.  Some of us knew the definition of connection was wrong 
in 78, but we didn't have the proof yet.  Doing the application layer 
structure provided that argument.

>but an association does not necessarily link two processes on the 

Sorry but this is incorrect.  An association (as defined by X.200 
does) link two processes on the communicating sides and involves 
algorithms on both sides.  (see above)

Take care,
John Day
Rapptorteur OSI Reference Model, 1980 - 1997

---

From: "t.petch" <[email-masked]>
Date: Sun, 8 Jan 2012 09:03:13 +0100

----- Original Message -----
From: "Dave CROCKER" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: "IETF-Discussion" <[email-masked]>
Sent: Friday, January 06, 2012 4:17 AM

analogy.
> > What seemed to me the closest analog to "process" would be the actual
messages
> It would be nice if it were a single word.

I agree that a message is not the right word, but I think that protocol is:-)
'Protocol' started as the draft treaty that formed part of diplomatic exchanges,
ie it was the physical manifestation, not the abstract concept, so I would use
it in that sense for networking.

For the abstract side of networking, I would use the same terminology as I would
use for a 'program'.  After all, a network is just a single, multi-tasking
system in which the 'links' that tie together the multiple tasks have been
stretched a little and made manifest so I use the same constructs, the same
tools - eg state machines - for both.  In a multi-tasking operating system, you
will have post and wait and some such, in a network you have send and receive
and some such, same difference.

Tom Petch

---

From: John Day <[email-masked]>
Date: Sun, 8 Jan 2012 07:00:52 -0500

Your are correct.  In fact, from the beginning the ARPANET and 
CYCLADES groups saw this as a distributed computing problem.  We have 
often said that much of the reason that early effort was a success is 
that we were operating systems guys not telecom guys.

The early applications were all aimed at replicating OS functionality 
in the network.  My favorite "proof" of this is that contrary to what 
many textbooks say, Telnet is not a remote login protocol; but a 
terminal device driver protocol.  But there was much work prior to 
1975 on the network as distributed computation.  The problem was our 
ideas were ahead of what the hardware could do "cheaply."  Even so, 
by 1975 we had fielded an application that implemented a land use 
planning system that used databases on both coasts invisibly to the 
user sitting at a plasma screen with touch. The keyboard was only for 
data entry. (There were other equally ambitious efforts) Somehow this 
direction was lost and we took a step backwards to a focus on 
"endpoints" as it has been characterized.)

You are also correct that strictly speaking the words "protocol" and 
"algorithm" are probably the same.  Other fields, such as biology, 
use protocol to mean the list of steps to produce something.

There has always been a debate about the abstract definition of 
"process." (To punt the definition I have thought of it as "a locus 
of execution" or "the instantiation of a program" but of course those 
beg other questions.) ;-)  Which is why OSI gave up and adopted 
"entity" as about the only word they could find that didn't have 
implications about how it was implemented.

Take care,
John

---

From: Martin Sustrik <[email-masked]>
Date: Sun, 08 Jan 2012 23:38:28 +0100

On 08/01/12 13:00, John Day wrote:

> "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).

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.

Martin

---

From: John Day <[email-masked]>
Date: Sun, 8 Jan 2012 23:35:05 -0500

At 23:38 +0100 2012/01/08, Martin Sustrik wrote:
>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.

>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.

Take care,
John Day

---

From: Martin Sustrik <[email-masked]>
Date: Mon, 09 Jan 2012 15:29:15 +0900

On 01/09/2012 01:35 PM, John Day wrote:
> 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.
>
> 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?

> 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.

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.

Martin

---

From: John Day <[email-masked]>
Date: Mon, 9 Jan 2012 07:08:05 -0500

At 15:29 +0900 2012/01/09, Martin Sustrik wrote:
>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.

>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.

>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

---

From: pankaj kumar <[email-masked]>
Date: Mon, 9 Jan 2012 20:00:41 +0530

What I feel that protocol is rules for any mode of communication or for
exchange of data.
e.g. - People speaks in English and English grammar is kind of protocol
otherwise it is difficult to understand communication if sentences are not
properly as per grammar. Now you can have a point that even we can
understand semantic of the sentence even if it is not correct as per
grammar; it is because we are human being and we can understand by guessing
intelligence. But it is difficult/impossible in networking to transfer data
without protocol because at every received byte or every received chunk of
bytes you can not have artificial intelligence to decode the received data.

other example: you have some rules to play every games- rules in chess,
football, tennis etc.

In this way I understand protocol is must and needed set of rules in every
communication (networking  or in-human) special to make it is successful.

Otherwise without protocol, things will be left on wild guess or on sixth
sense of the system.

On Mon, Jan 9, 2012 at 4:08 AM, Martin Sustrik <[email-masked]> wrote:

> 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).
>
> message-based underlying transport is sufficient) but a lot of algorithmic
> stuff. Consequently, it was often dismissed as not being a protocol.
>
> Martin
>
>
> ______________________________**_________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ietf<https://www.ietf.org/mailman/listinfo/ietf>
>

-- 
Thanks & Regards,

Pankaj Kumar,

Mobile: +91 8939008891
http://in.linkedin.com/in/techiepankaj

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Jan 2012 06:39:24 -0800

> I agree that a message is not the right word, but I think that protocol is:-)

There is a specific distinction that is intended by having two different words: 
  description vs. operation.

A program is a description of behavior.  A process is the operation of the 
description.  It is the behavioral performance.

Protocol refers to the description of an interaction.  The term being explored 
is for the operation of that description. It is the interaction.

> use for a 'program'.

If you mean that you would say 'process' for both, that does have the appeal of 
familiarity, but the problem of overloading.  Worse, I'd fear that it encourages 
a failure to appreciate the differences between networking architecture and 
software implementation.  Since this failure is quite prevalent, I suggest we 
not encourage it.

d/
-- 

   Dave Crocker

---

From: John Day <[email-masked]>
Date: Mon, 9 Jan 2012 10:36:59 -0500

At 6:39 -0800 2012/01/09, Dave CROCKER wrote:
>There is a specific distinction that is intended by having two 
>different words:  description vs. operation.
>
>A program is a description of behavior.  A process is the operation 
>of the description.  It is the behavioral performance.
>
>Protocol refers to the description of an interaction.  The term 
>being explored is for the operation of that description. It is the 
>interaction.
>

Agreed.

>If you mean that you would say 'process' for both, that does have 
>the appeal of familiarity, but the problem of overloading.  Worse, 
>I'd fear that it encourages a failure to appreciate the differences 
>between networking architecture and software implementation.  Since 
>this failure is quite prevalent, I suggest we not encourage it.

Well, pretty close.  There is a copious literature on the formal 
description and verification of protocols beginning in the 70s.

There are two major issues that is not normally found in defining a 
"program":  1) is specifying the asynchrony, ensuring no races, and 
2) keeping the specification implementation independent.  One does 
not want the specification to unnecessarily constrain the 
implementation strategy.  The general rule is Day's First Rule of 
Architecture:  Anything you can get away with that is undetectable 
from the outside is legal.  Or when it comes to implementation sleaze 
the architecture.

We have seen the problems of code monoculture or just assuming the 
other guys knew how to code.

Take care,
John

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 10 Jan 2012 14:53:50 +0000

<You are also correct that strictly speaking the words "protocol" and 
< "algorithm" are probably the same.

No, they aren't.

In protocols it is essential that there are at least 2 communicating entities running the same protocol (or at least compatible protocols).
Each side may be running algorithm(s), but the protocol states what I have to do when
the other side sends (or doesn't send) me a message of a certain type.

Algorithms frequently have inputs, but these need not come from other algorithms,
and are treated accordingly.

Y(J)S

---

From: John Day <[email-masked]>
Date: Tue, 10 Jan 2012 10:07:25 -0500

What you say is true of "communication or network protocols."

The statement below was written in the context of the wider use of 
the word protocol (and what you would probably find in the 
dictionary) in the fields of biology, chemistry, and diplomacy.

In this case, one could view our use of the term as a specialization 
of the general use.  After all, a network protocol is a distributed 
algorithm.  The communicating peers only make sense together.

At 14:53 +0000 2012/01/10, Yaakov Stein wrote:
>In protocols it is essential that there are at least 2 communicating 
>entities running the same protocol (or at least compatible 
>protocols).

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jan 2012 18:23:40 -0800

On 1/3/2012 5:53 PM, Kaushal Shriyan wrote:
> Hi,
>
> Can someone please explain me the term "Protocol". Does it also mean it
> has some software code underlying beneath it. Please help me understand.

My 2 cents:

A protocol is a defined set of rules that function at multiple locations 
(communication endpoints) that enable shared state (communication), and 
is composed of:

	a defined set of messages ("on the wire" part)
	a defined set of states (localized endpoint state)
	a set of rules that relate message arrival, message departure,
	time (optionally), and state transition

It's a lot like computation where the input is the received message 
sequence and the output is the transmitted message sequence.

A protocol is to communications as an algorithm is to computation.

Code can be used to implement an algorithm.

Code can be used to implement a protocol on an endpoint.

I.e., a protocol is just a special kind of algorithm - one that is used 
to support communication.

A running algorithm is called a process or thread (typically). Since a 
protocol *is* an algorithm, a running protocol is just called a 
communicating process or thread, IMO.

A "session" or "connection" defines an association between multiple 
parties running the same protocol and thus communicating.

Joe