Re: Protocol Definition
On 6/22/2012 10:17 AM, Tony Finch wrote: Randy Bush ra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. what a laugh. try, for example, RFC 826 Perhaps a better example is RFC 6325. Tony. Try this The IETFis and open and fair framework produces standards for use in both networking and internetworking services for global communication and the reasoning is that when ITU and other orgs like it were formed there was not Internetworking or Local Area Networks and so the IETF was formed to emerge the need to facilitate standards in these two key areas which other groups like ITU and IEEE with the underlying 802 work were not providing. -- //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: Protocol Definition
Randy Bush ra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. what a laugh. try, for example, RFC 826 Perhaps a better example is RFC 6325. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty: Northeasterly backing westerly, 5 or 6. Moderate or rough. Occasional rain. Moderate or poor.
Re: Protocol Definition
How about RFC 1661. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Fri, Jun 22, 2012 at 1:17 PM, Tony Finch d...@dotat.at wrote: Randy Bush ra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. what a laugh. try, for example, RFC 826 Perhaps a better example is RFC 6325. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty: Northeasterly backing westerly, 5 or 6. Moderate or rough. Occasional rain. Moderate or poor.
Re: Protocol Definition
I got help from a friend, to amend the definition statement to: All protocols in IETF are based on the Internet or/and the IP. AB Defining any protocol has to consider somehow it's networks On 6/18/12, Abdussalam Baryun abdussalambar...@gmail.com wrote: IMO the important issue in any definition is to include how the IETF defines protocol, this may be find in some RFCs :) The IP is the main protocol, and all protocols in IETF are based on IP and Internet. AB
Re: Protocol Definition
All protocols in IETF are based on the Internet or/and the IP. what a laugh. try, for example, RFC 826 randy
Re: Protocol Definition
On 6/22/12, Randy Bush ra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. RFC 826 read in first page [The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is a issue of general concern in the ARPA Internet community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of a Internet Standard.] randy
Re: Protocol Definition
On 6/21/12 20:57 , Abdussalam Baryun wrote: On 6/22/12, Randy Bush ra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. RFC 826 read in first page [The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is a issue of general concern in the ARPA Internet community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of a Internet Standard.] http://tools.ietf.org/html/rfc5921 This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS- TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. randy
Re: Protocol Definition
On 6/21/12 9:16 PM, Joel jaeggli wrote: On 6/21/12 20:57 , Abdussalam Baryun wrote: On 6/22/12, Randy Bushra...@psg.com wrote: All protocols in IETF are based on the Internet or/and the IP. [ ... ] http://tools.ietf.org/html/rfc5921 I dunno - once you throw based on the Internet in there pretty much anything goes. Which is not to say that I think his definition of protocol is helpful, since it does not appear to actually *be* a definition. But anyway, I was surprised by some of things for which I haven't been able to find a definition in IETF documents - for example, state, although that's an extremely difficult term for which to do an exhaustive search and it's very likely out there but hard to find. Melinda
Re: Protocol Definition
On Tue 19/Jun/2012 00:44:25 +0200 Joe Touch wrote: On 6/18/2012 3:30 AM, Alessandro Vesely wrote: ... one can give a full description (or coding) of, say, sqrt, without actually saying that the square of the result will match its argument up to some rounding error. The specification does not have to relate the underlying mathematical abstraction. This is the difference between a behavioral description and a procedural description. Behavioral treats a system as a black box, and defines the system as a function and how it transforms its input into its output. Procedural specifies the particular steps taken inside the box. Procedural is more specific than behavioral: behavioral = any of a number of ways of calculating SQRT procedural = one specific algorithm for calculating SQRT Semantics is a completely different thing - the assignment of meaning to symbols. Neither procedural nor behavioral descriptions need to include semantic descriptions. We agree that including semantic descriptions is optional. But what is better? For SQRT, I'd hold that a short, crispy reference to the theoretical background may be useful and wouldn't harm. For the general case, I'm not sure. Protocol specifications, especially when dealing with policies, do not have to describe the exact meaning of the relevant tokens. To do that would often look like mandating a state or a reaction, neither of which is needed to ensure interoperability. In a protocol, state transitions and response messages are specified. When they're part of the protocol proper, they are specified indeed. Policy tweaks, however, live in some limbo. For example, recursion for DNS, access restrictions for HTTP, ADSP for SMTP. Specifications can hardly discuss such topics. If they do, they get criticized for interfering with deployment. In addition, as policies typically involve subjective considerations, it is quite rare to gather rough consensus on any specific advice about them. Protocols are typically described procedurally, FWIW. Yes. And quite often a procedural description is the most accurate way to reverse engineer the actual meaning of a message. Policies don't enjoy such practice. In fact, the protocol just has to ensure that a policy can be transmitted correctly. Many would rather leave a policy token underspecified than get involved in its details. This is like claiming that a protocol is just bits on the wire, and it is not accurate. Well, it is not accurate to assume full knowledge about the policies and their consequences. Let me try and express that better below. Conduct, intention, and semantics refer to human interpretations of events. Unless a human is part of your protocol stack, they're not relevant. I agree with AB - these issues aren't relevant to IETF descriptions of protocols. Besides development, humans typically configure some implementations of one or more protocols. That is what makes protocols run, so it has to be relevant to us. Hostmasters who carry out that task are skilled staff. However, they have to infer the exact meaning of a policy token by the wording of its definition and/or by trial and error, neither of which seems to be formally adequate to me. What am I missing?
Re: Protocol Definition
On 5 Jan 2012, todd glassey tglas...@earthlink.net wrote On 1/5/2012 6:48 AM, Dave CROCKER wrote: (One can quibble about the difference between algorithm and program. An 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... I noticed no disagreement between method and mechanism, at the time. In retrospect, those two terms might seem to allude to a different depth of semantic explanations. Rereading that thread, I find that the same ambiguity holds for algorithm descriptions: one can give a full description (or coding) of, say, sqrt, without actually saying that the square of the result will match its argument up to some rounding error. The specification does not have to relate the underlying mathematical abstraction. Protocol specifications, especially when dealing with policies, do not have to describe the exact meaning of the relevant tokens. To do that would often look like mandating a state or a reaction, neither of which is needed to ensure interoperability. In fact, the protocol just has to ensure that a policy can be transmitted correctly. Many would rather leave a policy token underspecified than get involved in its details. In that respect, a protocol is not a complete method. The upper layer, where policies and politics are dealt with, seems to be too fuzzy to be specified. I think this limitation is consistent with the etymological meaning of the term, that refers to forms of conduct that don't betray intentions. Is that right?
Re: Protocol Definition
IMO the important issue in any definition is to include how the IETF defines protocol, this may be find in some RFCs :) The IP is the main protocol, and all protocols in IETF are based on IP and Internet. AB On 5 Jan 2012, todd glassey tglassey at earthlink.net wrote On 1/5/2012 6:48 AM, Dave CROCKER wrote: (One can quibble about the difference between algorithm and program. An 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... I noticed no disagreement between method and mechanism, at the time. In retrospect, those two terms might seem to allude to a different depth of semantic explanations. Rereading that thread, I find that the same ambiguity holds for algorithm descriptions: one can give a full description (or coding) of, say, sqrt, without actually saying that the square of the result will match its argument up to some rounding error. The specification does not have to relate the underlying mathematical abstraction. Protocol specifications, especially when dealing with policies, do not have to describe the exact meaning of the relevant tokens. To do that would often look like mandating a state or a reaction, neither of which is needed to ensure interoperability. In fact, the protocol just has to ensure that a policy can be transmitted correctly. Many would rather leave a policy token underspecified than get involved in its details. In that respect, a protocol is not a complete method. The upper layer, where policies and politics are dealt with, seems to be too fuzzy to be specified. I think this limitation is consistent with the etymological meaning of the term, that refers to forms of conduct that don't betray intentions. Is that right?
Re: Protocol Definition
On 6/18/2012 3:30 AM, Alessandro Vesely wrote: ... I noticed no disagreement between method and mechanism, at the time. In retrospect, those two terms might seem to allude to a different depth of semantic explanations. Rereading that thread, I find that the same ambiguity holds for algorithm descriptions: one can give a full description (or coding) of, say, sqrt, without actually saying that the square of the result will match its argument up to some rounding error. The specification does not have to relate the underlying mathematical abstraction. This is the difference between a behavioral description and a procedural description. Behavioral treats a system as a black box, and defines the system as a function and how it transforms its input into its output. Procedural specifies the particular steps taken inside the box. Procedural is more specific than behavioral: behavioral = any of a number of ways of calculating SQRT procedural = one specific algorithm for calculating SQRT Semantics is a completely different thing - the assignment of meaning to symbols. Neither procedural nor behavioral descriptions need to include semantic descriptions. Protocol specifications, especially when dealing with policies, do not have to describe the exact meaning of the relevant tokens. To do that would often look like mandating a state or a reaction, neither of which is needed to ensure interoperability. In a protocol, state transitions and response messages are specified. Protocols are typically described procedurally, FWIW. In fact, the protocol just has to ensure that a policy can be transmitted correctly. Many would rather leave a policy token underspecified than get involved in its details. This is like claiming that a protocol is just bits on the wire, and it is not accurate. In that respect, a protocol is not a complete method. The upper layer, where policies and politics are dealt with, seems to be too fuzzy to be specified. I think this limitation is consistent with the etymological meaning of the term, that refers to forms of conduct that don't betray intentions. Is that right? Conduct, intention, and semantics refer to human interpretations of events. Unless a human is part of your protocol stack, they're not relevant. I agree with AB - these issues aren't relevant to IETF descriptions of protocols. Joe
Re: Protocol Definition
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Protocol Definition
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Protocol Definition
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 + 2012/01/10, Yaakov Stein wrote: 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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 sust...@250bpm.com 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). 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 __**_ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/**listinfo/ietfhttps://www.ietf.org/mailman/listinfo/ietf -- Thanks Regards, Pankaj Kumar, Mobile: +91 8939008891 http://in.linkedin.com/in/techiepankaj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
On 1/8/2012 12:03 AM, t.petch wrote: 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. For the abstract side of networking, I would use the same terminology as I would 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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
At 6:39 -0800 2012/01/09, Dave CROCKER wrote: On 1/8/2012 12:03 AM, t.petch wrote: 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. Agreed. For the abstract side of networking, I would use the same terminology as I would 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
- Original Message - From: Dave CROCKER d...@dcrocker.net To: Joel M. Halpern j...@joelhalpern.com Cc: IETF-Discussion ietf@ietf.org Sent: Friday, January 06, 2012 4:17 AM 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. 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 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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 At 9:03 +0100 2012/01/08, t.petch wrote: - Original Message - From: Dave CROCKER d...@dcrocker.net To: Joel M. Halpern j...@joelhalpern.com Cc: IETF-Discussion ietf@ietf.org Sent: Friday, January 06, 2012 4:17 AM 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. 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 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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). 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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. 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. Take care, John Day Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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? 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Protocol Definition
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: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, January 06, 2012 05:03 To: Dave Cridland Cc: IETF-Discussion Subject: Re: Protocol Definition 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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Protocol Definition
At 20:11 + 2012/01/07, Yaakov Stein wrote: 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. 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.) 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). 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 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. 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 Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, January 06, 2012 05:03 To: Dave Cridland Cc: IETF-Discussion Subject: Re: Protocol Definition 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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo
Re: Protocol Definition
On 1/4/2012 2:07 AM, Yaakov Stein wrote: 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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? It's tempting to say port number, but that doesn't seem very satisfying. Session? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
(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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
--On Thursday, January 05, 2012 06:48 -0800 Dave CROCKER d...@dcrocker.net wrote: (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.) 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. 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. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
On 1/5/2012 6:48 AM, Dave CROCKER wrote: On 1/4/2012 2:07 AM, Yaakov Stein wrote: 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 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. My question is: If protocol corresponds with program or algorithm, then what is the 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 satisfying. No, you are right here and it's because there may be no ports/sockets in the protocol as in IPC for instance. d/ -- 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
On 1/5/2012 7:01 AM, Dave Cridland wrote: 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? It's tempting to say port number, but that doesn't seem very satisfying. Session? 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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
On 1/5/12 9:13 AM, Dave CROCKER wrote: On 1/5/2012 7:01 AM, Dave Cridland wrote: 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? It's tempting to say port number, but that doesn't seem very satisfying. Session? 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
On 01/05/2012 11:48 AM, Dave CROCKER wrote: If protocol corresponds with program or algorithm, then what is the communications term that corresponds to process? Protocol Machine. or Protocol Instance. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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: 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/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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 Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Protocol Definition
A protocol is to communications what an algorithm is to computation. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ole Jacobsen Sent: Wednesday, January 04, 2012 03:59 To: Kaushal Shriyan Cc: ietf@ietf.org Subject: Re: Protocol Definition 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: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Wed, 4 Jan 2012, 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. Regards, Kaushal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Definition
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol Definition
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: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Wed, 4 Jan 2012, 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. Regards, Kaushal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
