Talk:Internet protocol suite/Archive 3

Archive 1

Archive 2

Archive 3

IP stack connections diagram

A diagram has been replaced in the Internet protocol suite#Key architectural principles section:
The following discussion is based on the 8 July 2018 version of the new image which showed "app-to-app" at the Application layer and "process-to-process" at the Transport layer.

Old image by Kbrose and Cburnett.	New image by JensLechtenboerger.

The old diagram is correct: the source and destination hosts communicate via the Transport layer within the operating system at each end. The Transport layer sends/receives data on behalf of a process which can be regarded as operating at the Application layer. Perhaps some words are required to explain the diagram, but it correctly reflects TCP/IP procedures. The point is that a process is a program loaded and run by the operating system (process = application). The host-to-host communication is handled by the operating system which is the Transport layer. Johnuniq (talk) 05:52, 9 July 2018 (UTC) (I replaced some text above with a table showing the images. Johnuniq (talk) 09:46, 9 July 2018 (UTC))

I don't fully agree with either version. The IP/network layer is host-to-host. The transport layer provides process-to-process connectivity while the application layer is process-to-process as well but on a higher abstraction level and (often) outside the OS's scope. --Zac67 (talk) 07:24, 9 July 2018 (UTC)

References

Johnuniq, can you cite any textbook on computer networks that supports your view? Hosts do not communicate at the Transport layer, processes on those hosts do. Of course, operating systems are involved when delivering messages to processes but that does not matter here. IP communication is host-to-host. I don't see anything in Zac67's comment that contradicts my figure. (Yes, app-to-app is a term that I made up. As application specific protocols are used here to transmit messages over the underlying process-to-process protocol, that seemed appropriate to me.) JensLechtenboerger (talk) 17:12, 9 July 2018 (UTC)

@JensLechtenboerger:: Yes, the process-to-process change is an improvement; I'm not too fond of the "app-to-app" though, it's ambiguous. If we need a host-to-host it must be on the network layer. --Zac67 (talk) 17:36, 9 July 2018 (UTC)

Internet protocol suite provides correct explanations of the layers. Lightly paraphrased, it says that applications (processes) communicate over the application layer, while the transport layer (TCP or UDP) performs host-to-host communications. To elaborate, processes communicate using a higher-level protocol, for example, FTP. An FTP client in one host sends a request to an FTP server in another host. That is process-to-process communication using the rules of FTP. The data stream is handled by TCP in the transport layer within the operating system. That is host-to-host communication because the OS in each host tracks its TCP connections and handles out-of-order or failed packets. Each host also handles the IP layer and communication with the network adapter (link layer). However, IP is hop-to-hop with no error recovery. It is TCP that provides end-to-end intelligence where one host prompts the other host regarding whether data has been received or should be re-sent. RFC 791 and 793 do not contradict these facts. RFC 793 is saying that the purpose of TCP is to provide a reliable communication layer for processes in the application layer. TCP/IP Illustrated is the bible for this sort of thing. In that book, Figure 1.2 shows an example of an FTP client and server communicating at the application layer, labeled as "user processes". The transport layer and below are labeled "kernel", that is, the operating system. Many other explanations in the book confirm that the old diagram is correct. Johnuniq (talk) 01:56, 10 July 2018 (UTC)

While the transport layer functions are provided by the host OS it interconnects processes and provides process-to-process communication. It's very easy to mix this up. Figure 2.1 in TCP/IP Illustrated very clearly shows the implementation details. However, it talks a lot about the end-to-end paradigm which is host-to-host for the network layer and process-to-process for the transport layer. --Zac67 (talk) 07:59, 10 July 2018 (UTC)

Can we get explicit about the meanings of "process" and "host"? Suppose that at host A someone runs an FTP client which downloads a file from host B running an FTP server. Would you agree that the running FTP client and server programs are the two processes? And process-to-process communication refers to the exchange of data between the FTP client and server using the FTP protocol?

Identifying the meaning of "host" is more tricky because that term refers to hardware and the software that controls the hardware. A host has a network adapter and an IP address associated with that adapter. Do you agree that passing packets between adapters is not what is meant by host-to-host communication? By "network layer" do you mean layer 3 in the OSI model? It might be clearer here to use the terms shown in the diagrams for TCP/IP above. Are you suggesting host-to-host communication occurs at the Internet (IP) layer? Johnuniq (talk) 10:09, 10 July 2018 (UTC)

A "host" is the hardware and operating system of a full stack node (compare RFC 1122 1.1.1) while a process is a (user) program running on that OS. Yes, the FTP server and client are the processes communicating. Process-to-process communication is what the application protcol requires, in your example that's FTP's underlying TCP socket. The socket is a logical, two-way communication channel (stream) connecting the server and client processes with each other. The application layer is sitting on top of that as a 'language' to give the transmitted stream a meaning. Note that the stream is already process-to-process. The host/OS doesn't care about it, it just provides the socket service and passes the data. Passing data between network adapters is actually node-to-node (OSI L2) which – using routers – can be extended to pass packets end-to-end between hosts (OSI L3). Yes, the network layer is OSI layer 3, or the internet layer in the IP or DoD model. Yes, I'm suggesting host-to-host is done in OSI L3, see the reference to RFC 791 above. --Zac67 (talk) 12:24, 10 July 2018 (UTC)

I don't have time to get caught up on the whole discussion here. For now I'll just chime in and say that the new diagram is an improvement WRT to old so should stay. The transport layer has port numbers and so is process-to-process, not just host-to-host. ~Kvng (talk) 19:49, 10 July 2018 (UTC)

I've read some more of this discussion and am reminded that people get religious about layers. I have previously resolved to not get sucked into these discussions and I will try hold myself to that. ~Kvng (talk) 15:05, 12 July 2018 (UTC)

@Kvng: Yeah, I see that. At least I'm not the one that's confused and I've got other fish to fry as well. --Zac67 (talk) 09:42, 13 July 2018 (UTC)

I created the diagram back in 2007. My citation would be Forouzan, Behrouz (2003). TCP/IP Protocol Suite (2nd ed.). McGraw Hill. p. 34. ISBN 0-07-246060-1.:

The transport layer is represented in TCP/IP by two protocols: TCP and UDP. The IP is a host-to-host protocol, meaning that it can deliver a packet from one physical device to another. UDP and TCP are transport level protocols responsible for delivery of a message from a process (running program) to another process.

If you look at my versions, I use "peer-to-peer" rather than host or process. However, I would agree that saying transport layer is host-to-host is incorrect and I'll use my textbook citation as my reference. My preference would be to strike both versions and go back to a more simple "peer-to-peer" to avoid the semantics. The layers are not required of TCP/IP stack and it is absolutely legit for an application to skip the transport layer and talk IP directly if it wants to.

I also don't like "app-to-app". Mostly because the word "app" didn't exist when TCP/IP was crafted and later was used mainly in the phrases like "killer app" and "app" wasn't really en vogue until smart phones and app stores. Plus saying the application layer is "app-to-app" is redundant and non-informative.

Really, I think "peer-to-peer" summarizes it the best, which is what I put there 11 years ago... (PS: thanks for the nostalgic trip back in time.) Cburnett (talk) 01:54, 11 July 2018 (UTC)

Peer-to-peer has a specific meaning, which is not adequate here. Client-server is not peer-to-peer, for example. JensLechtenboerger (talk) 06:13, 11 July 2018 (UTC)

BTW, Kbrose reverted to the old, incorrect version. I give up here. Please read the references given by Zac67 above. JensLechtenboerger (talk) 06:20, 11 July 2018 (UTC)

I don't know why people get so confused about layers but both the article and my comments have explained the situation well. A small clue should come from reading the article and seeing that it contradicts the new diagram—doesn't that make you want to rethink the issue? Johnuniq (talk) 07:37, 11 July 2018 (UTC)

@Johnuniq: I'm not going to enter an edit war – I've explained, I've sourced, you don't seem to understand and you revert without consent. What can we do more? --Zac67 (talk) 07:59, 11 July 2018 (UTC)

Please at least acknowledge what I have written. Are you happy to post a diagram that contradicts the article, or did you not notice? The sources do not say what you think. Johnuniq (talk) 08:16, 11 July 2018 (UTC)

When the article is wrong or ambiguous it needs to be corrected or sharpened, we need to start somewhere. Over the years, I've rewritten a few articles that were ambiguous or outright wrong (e.g. Virtual LAN was horrible. What do you think the sources say? Aren't the quotations above very clear? --Zac67 (talk) 08:39, 11 July 2018 (UTC)

The point of layering is to provide data abstraction. It is possible to look at TCP (in the transport layer) and say that it connects client and server processes and so in some way is process-to-process. However that fails to account for what layering is. Using TCP as an example, the transport layer understands the rules of TCP but has no idea about how FTP works (in the higher application layer), nor how IP routing works (in the lower internet layer). Using FTP as an example, an FTP client exchanges FTP messages with an FTP server and gets data and status responses using the rules of FTP. That is the application layer where one process (an FTP client) exchanges data with another process (an FTP server). Once the principles of layering are understood, it follows that the application layer handles process-to-process protocols (FTP, HTTP, and so on), while the transport layer handles host-to-host protocols (TCP, UDP). I could expand on what host-to-host means but I've posted too much for others to read already. Johnuniq (talk) 09:30, 11 July 2018 (UTC)

I'm pretty familiar with the OSI and DoD stacks. Your argument seems to be "application layer is process-to-process, so the lower transport layer needs to be host-to-host" – this is at least somewhat wrong. Each layer has an interface to the next lower layer ("lower interface"), an interface to the next higher layer ("upper interface") and its internal workings. When looking at a layer from a distance, the most prominent feature is its upper interface – the function it provides. The internet layer transports packets from host to host. The transport layer transports user datagrams or data streams from process to process. Anything wrong here? Of course, the transport layer uses a host-to-host connection as its lower interface (provided by the internet layer) – this seems to be your point. Essentially, we've got to get the wording right. I'd suggest something along the line "the transport layer provides process-to-process communication", which you don't dispute I hope. --Zac67 (talk) 12:59, 11 July 2018 (UTC)

FTP might not have been the best example. Look at what a NAT router needs to do. IP routers are supposed to be at layer 3, but FTP puts port numbers inside its data stream. NAT rewrites port numbers, so for FTP to work, has to change those port numbers. It has to know details of the FTP protocol that it shouldn't need to know. The layer idea is nice, but if you look too close, you find it doesn't work as well as it should. My always favorite example is ICMP, which should be an IP carried protocol, like TCP and UDP, and pretty much is for ping, but also does low level functions, like report unreachable or other problems that belong to layer 2. It is all nice theory, but when you get down to the fine details, it isn't quite so nice. Gah4 (talk) 23:30, 22 July 2018 (UTC)

Zac67's notion of TCP/IP communication is simply wrong. TCP/IP nowhere specifies what kind of interface are to be presented to another layer. TCP/IP networking layers are simply scope-based. The layers are loosely defined realms of communication. The precise extraction of interface definitions was exclusively the idea of OSI. TCP/IP of course specified detailed protocol interfaces, but the notion of layer-detailed specifications is largely unpracticed, even considered hostile to effective communication in the IETF. Indeed the first round of OSI implementations were un-interoperable with each other, while TCP/IP succeeded without this burden. The Internet Layer does not provide host-to-host communication in the TCP/IP scheme. Its name reveals its purpose, coming from internetworking, it provides an unreliable packet routing service to connect networks. Of course as such it interacts with hosts as well, because a router in essence can also be considered a host with lesser capability, but a router does not require a transport layer protocol. Having a transport layer protocol is essential for what is considered to be host-to-host communication in TCP/IP. Delivering packets to a host (in the IP layer) is not communication. Processes-to-process communication happens in the Application Layer. Applications are built from processes. At this layer, the process needs to know nothing about how data is actually transmitted across the network from host to host; it doesn't need to be concerned with IP addresses, hostnames, etc., with the exception of course that it needs to provide some data first about its communication peers. On the host-to-host level, the communications stack knows little or nothing about the structure or meaning of the application data, it just knows how the get same data to another host. This is the transport. The Internet Layer knows nothing much about the hosts, or even the type of transport protocol, it just knows how to send chunks of data (packets) to the next router, which is presumably a step closer to the destination, and has presumably an operating link. The Link Layer is the scope for communication just on the local network connected to a network interface of a host or router. How that happens was not the concern of the TCP/IP developers, and thus the suite has no physical layer. To read much more into TCP/IP networking concepts is a fallacy. This scheme is embedded in the early RFCs of the model, which are cited throughout this article. Kbrose (talk) 16:36, 11 July 2018 (UTC)

Historical note

The early DOD network model only distinguished a single layer in place of the layers for internetworking and transport, which was instantiated by a single piece of software, the Transmission Control Program (TCP). It was referred to also as the host-to-host protocol. The TCP (program) was later split into TCP (protocol) and IP, so that the unreliable packet delivery was separated into another layer. Therefore it is also clear historically, that the host-to-host nomenclature belongs to the Transport Layer. Certainly, packets are delivered to hosts in the Internet Layer, but this does not constitute any recognition of any kind of communication session between hosts in the Internet Layer; rather it could be categorized as host-to-network, or network-to-host. Kbrose (talk) 17:45, 11 July 2018 (UTC)

Agree the old version is correct. The notion of "apps" is a recentism. All kinds of stuff can be done with TCP/IP with a few lines of code in temporary scripts or even directly on the commandline, and I don't think people would conceptualize these as "apps". The fact that physical hosts today can be virtualized and simulated doesn't change the nature of the protocol layer, just the in situ definition of "host".  — SMcCandlish ☏ ¢ 😼  22:34, 11 July 2018 (UTC)

I just added another authoritative book (TCP/IP Network Administration by Craig Hunt) as a reference for the transport layer description. Section 1.3 from the book starts with a paragraph which includes "The four-level model illustrated in Figure 1.2 is based on the three layers (Application, Host-to-Host, and Network Access) shown in the DOD Protocol Model in the DDN Protocol Handbook - Volume 1, with the addition of a separate Internet layer." Figure 1.2 ("Layers in the TCP/IP protocol architecture") shows the following:

4 Application Layer consists of applications and processes that use the network

3 Host-to-Host Transport Layer provides end-to-end data delivery services

2 Internet Layer defines the datagram and handles the routing of data

1 Network Access Layer consists of routines for accessing physical networks

Section 1.6 starts with "The protocol layer just above the Internet Layer is the Host-to-Host Transport Layer. This name is usually shortened to Transport Layer." Johnuniq (talk) 02:23, 12 July 2018 (UTC)

RFC 793 is the TCP standard. It starts "The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in ... networks." A diagram shows TCP at layer 3, with layer 4 being "higher-level" and layer 2 being "internet protocol".

RFC 791 is the IP standard. It includes "There are no mechanisms [in IP] to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols." Johnuniq (talk) 08:18, 12 July 2018 (UTC)

My two comments just above show simple and strong support for the old diagram. There has been no response to the evidence but apparently there is still disagreement. The reason the transport layer (but not the internet layer) is host-to-host comes from considering the diagram and determining what a router does. When a packet arrives at a router, it examines only the IP header. A router remembers nothing about previous packets, and the router does not communicate with the sender regarding the packet it has received—a router forwards packets (or drops them if unroutable or the router is busy), and that's it. By contrast, hosts A and B really do communicate over the transport layer—missed packets are resent and other controls are applied. Each host has to remember the state of each of its TCP connections. The TCP layer requires host-to-host communication whereas the IP and link layers do not. Johnuniq (talk) 10:18, 13 July 2018 (UTC)

We know all that and I'm not arguing any more. You seem to make a point of how a layer works and for me (and others) the main point is what kind of service a layer provides. I've taught quite a few people and they understand this way much easier than other approaches. The inner workings of a transport layer protocol can be quite different, depending on its service. Btw: the host itself doesn't care about anything inside the transport layer, this is the transport layer's responsibility (usually part of the host OS but not necessarily). Additionally, UDP as another transport layer protocol doesn't track packets (datagrams) or retransmit; it's also quite stateless. Please don't reply, we've heard it all.--Zac67 (talk) 11:02, 13 July 2018 (UTC)

This reply still shows that you do not understand the ideas of TCP/IP, but a talk page indeed is not the place to teach you. Briefly, for future editors here, TCP/IP is in fact not about the kind of service a layer provides. In TCP/IP layers are not intended or designed to provide something. They provide nothing. The layers are descriptions of the realm or scope of communication. Data abstraction is conveniently categorized in such terms without detailed rules of interface definitions for sessions, presentation, or mode of transmission. TCP/IP protocol designers don't care about layers, they are not bound to burdensome specifications or architecture. Even UDP communication, since you singled it out, implies a host-to-host association, it is just that the component for reliability (handshake) is designed at a higher level, when necessary; therefore protocols such as SIP, implement an extension of the Transport Layer for this purpose. Kbrose (talk) 16:48, 13 July 2018 (UTC)

I replaced "app-to-app", which confused people, with "application-specific". I'm confused that nobody seems to care about the RFC parts cited by Zac67 (but instead more "convenient" ones are presented as authoritative). Besides, the book by Craig Hunt does not have much value in our discussion because the author claims "the addition of a separate Internet layer" although the model cited by him already included that layer (as also pointed out by Kbrose above). Let's focus on facts: If I send an IP datagram from my machine, it will reach the destination host. Tools such as hping3 allow raw IP communication (send datagram from source host, listen for datagram on destination host, trigger action when it is received). If that is not host-to-host communication based on the IP, I'd like to know how you call that. A modern textbook for Computer Network courses (targeting "the graduate or upper-division undergraduate level") explaining that the transport layer is for process-to-process communication is , p. 33: “The transport layer then implements what we have up to this point been calling a process-to-process channel.” This is what my figure displays and what neither the article nor the current figure reflect. Wikipedia readers might want to know that IP datagrams travel from source host to destination host, and that TCP data is exchanged between processes identified by ports (and, yes, that can also happen in raw form without any higher-level protocol). JensLechtenboerger (talk) 14:28, 14 July 2018 (UTC)

References

@JensLechtenboerger: You're absolutely right but this "discussion" was getting too religious as Kvng called it. Older books and references have many discrepancies (even newer ones do) but that's no reason to carry those over to WP imho. Anyway – the article currently contradicts itself which doesn't help the cause but unless someone really authoritative steps in we probably can't help it. --Zac67 (talk) 17:48, 14 July 2018 (UTC)

The cited authors (Peterson et al.) develop a network model of their own design and transition it into the OSI model. You can't just pick out a sentence without context and claim to have a reference for your ideas. Peterson does not discuss TCP/IP in that context, and whether or not those ideas are valid for OSI is not the topic in this article, which is about the Internet Protocol Suite. Kbrose (talk) 00:08, 15 July 2018 (UTC)

@Kbrose: What Zac67 cited from RFC 793 has been ignored so far, so I chose a different source. (This is really not the point here but I wonder whether you just suggested that we need two articles on the Transport Layer, one for OSI, one for TCP/IP.) Yes, unfortunately, RFC 793 starts with this as first sentence: "The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks." For people inclined enough to continue reading, that gets clarified repeatedly subsequently, though: 1.1. Motivation: "The TCP provides for reliable inter-process communication between pairs of processes in host computers attached to distinct but interconnected computer communication networks." Then 1.2. Scope: "The TCP is intended to provide a reliable process-to-process communication service in a multinetwork environment." Then 1.4. Interfaces: "The TCP interfaces on one side to user or application processes and on the other side to a lower level protocol such as Internet Protocol." Then 1.5. Operation: "As noted above, the primary purpose of the TCP is to provide reliable, securable logical circuit or connection service between pairs of processes." So, clearly, TCP is a process-to-process layer. Then, let me cite this from RFC 1122: "The transport layer provides end-to-end communication services for applications." (Note that the article claims to use RFC 1122 as source but then uses Hunt's presentation, which is based on the strange argument of adding an "Internet layer" to something that already contains IP.) JensLechtenboerger (talk) 08:29, 15 July 2018 (UTC)

And let me add this on IP, also from RFC 1122: "All Internet transport protocols use the Internet Protocol (IP) to carry data from source host to destination host.". Thus, if the article is supposed to be based on RFC 1122, changes are necessary, including the figure. JensLechtenboerger (talk) 08:39, 15 July 2018 (UTC)

A similar argument may be made of any layer, even the Link Layer. That is not the defining statement of the layer. To carry data from source host to destination host, every layer is required. The idea of TCP/IP is that the abstraction in the layers separates them in their respective scope. Kbrose (talk) 20:54, 15 July 2018 (UTC)

“A similar argument may be made of any layer, even the Link Layer.” I don’t know how you arrived at that conclusion. How is that related to anything I wrote? JensLechtenboerger (talk) 15:20, 16 July 2018 (UTC)

“To carry data from source host to destination host, every layer is required.” That is incorrect and contradicts both figures. JensLechtenboerger (talk) 15:24, 16 July 2018 (UTC)

“The idea of TCP/IP is that the abstraction in the layers separates them in their respective scope.” Sure. However, so far, my part of the discussion was not about TCP/IP but about TCP and IP. Can we get back there, please? JensLechtenboerger (talk) 15:33, 16 July 2018 (UTC)

An FTP client communicates with an FTP server using the FTP protocol. The client and server processes communicate with each other over the application layer. Yes, they use the transport layer to do that, and that uses the internet layer which uses the link layer—all the layers are used to allow communication between client and server processes. Instead of cherry-picking text from RFCs, have a serious look at what they say. See my comments at 08:18, 12 July 2018 above for an accurate reading of the TCP standard. A good understanding of TCP/IP requires using network tools to capture and analyze packets to see what happens in the headers used by each layer. Such analysis shows a header for the application layer inside a header for the transport layer inside a header for the internet layer inside a header for the link layer. The protocols are defined by those headers. Note that the diagram includes Data Flow—that is why the old diagram is correct because it shows the layers used for data to flow from one end to the other. The data referred to is what is inside the header—the process data is prefixed with an application header. By your reading, the new diagram would have to show process data going vertically down from application to transport, then horizontally to the other transport, then vertically up to the destination application. Johnuniq (talk) 09:12, 15 July 2018 (UTC)

In more general terms, it is the data abstraction scheme that determines the scope of exchange. The Transport Layer is the first layer at which the data units (datagram or segment with headers) are identical at source and destination hosts. This is shown in the encapsulation diagram just below the topology. At the application level, only the application data is exchanged free of encapsulation preambles. The designers of TCP/IP faced a dilemma with the original monolithic design of the host-to-host protocol, the TCP, because it broke the envisioned data abstraction of scope. The result was the separation of the Internet Layer for catenet scoping, leaving the Transport Layer as the host-to-host layer. Kbrose (talk) 20:54, 15 July 2018 (UTC)

@Kbrose: “The result was the separation of the Internet Layer for catenet scoping, leaving the Transport Layer as the host-to-host layer.” My quotes from RFCs 791, 793, and 1122 contradict that statement. JensLechtenboerger (talk) 15:29, 16 July 2018 (UTC)

@Johnuniq: I agree until this: “Instead of cherry-picking text from RFCs, have a serious look at what they say. See my comments at 08:18, 12 July 2018 above for an accurate reading of the TCP standard.” I cited several parts of the TCP standard (RFC 793), clearly showing how its first sentence (cited by you) needs to be interpreted. If someone is cherry-picking here, that might not be me. Also, let’s add the sentences before and after the one that you cited from the IP standard (RFC 791): “The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service.” That just clarifies what functions/mechanisms (which you may expect from other host-to-host protocols) are not necessary for the source-to-destination protocol IP. Obviously, source and destination are hosts. Also, please do not make assumptions whether I analyzed packets or not. They seem to be incorrect. JensLechtenboerger (talk) 15:29, 16 July 2018 (UTC)

@Johnuniq: “By your reading, the new diagram would have to show process data going vertically down from application to transport, then horizontally to the other transport, then vertically up to the destination application.” Please do not make assumptions about my “reading.” They seem to be incorrect. JensLechtenboerger (talk) 15:29, 16 July 2018 (UTC)

Dispute on Transport layer: host-to-host, end-to-end, process-to-process, or all of them?

In Section "Key architectural principles," the transport layer in general and TCP in particular is presented as "host-to-host." Actually, the TCP standard RFC 793 starts with this as first sentence: “The Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet-switched computer communication networks, and in interconnected systems of such networks.”

So let’s fix this as first fact: TCP is a host-to-host protocol. Note that currently there is no article on Wikipedia explaining what a host-to-host protocol might be. So, classifying the TCP as host-to-host protocol will not help most readers.

The TCP specification, RFC 793, clarifies what TCP is supposed to offer repeatedly subsequently, though: 1.1. Motivation: "The TCP provides for reliable inter-process communication between pairs of processes in host computers attached to distinct but interconnected computer communication networks." Then 1.2. Scope: "The TCP is intended to provide a reliable process-to-process communication service in a multinetwork environment." Then 1.4. Interfaces: "The TCP interfaces on one side to user or application processes and on the other side to a lower level protocol such as Internet Protocol." Then 1.5. Operation: "As noted above, the primary purpose of the TCP is to provide reliable, securable logical circuit or connection service between pairs of processes."

So, let’s fix this as second fact: TCP offers process-to-process (alternatively: application-to-application) connectivity.

Actually, this is also supported by RFC 1122: "The transport layer provides end-to-end communication services for applications."

Besides, the article claims to use RFC 1122 as source but then uses a book by Hunt as source, which is based on the strange argument of adding an "Internet layer" to something that already contains IP as explained in the section on "IP stack connections diagram" above. Even worse, Hunt is mis-cited. As cited above, Hunt visualizes the transport layer with this description: “Host-to-Host Transport Layer provides end-to-end data delivery services” In the article, that seems to have turned into “The transport layer performs host-to-host communications.” Without further explanations I fail to see how “end-to-end data delivery services” can be equated with “host-to-host communications.”

I propose to remove the book by Hunt as reference and correct this sentence “The transport layer performs host-to-host communications on either the same or different hosts and on either the local network or remote networks separated by routers.” with that one, starting with a quotation from RFC 1122: “The transport layer provides end-to-end communication services for applications” on either the same or different hosts and on either the local network or remote networks separated by routers. Subsequently, other parts of the article can be corrected in that spirit (e.g., explaining process-to-process services of TCP more clearly and also explaining that IP offers host-to-host connectivity). I’m willing to do that, based on quotations from relevant RFCs, but after having an earlier edit in the above direction reverted with the comment “rv nonsense,” I’m afraid of wasting my time. JensLechtenboerger (talk) 14:43, 18 July 2018 (UTC)

References

This all started with a new diagram (now removed) as shown in the section above. The new diagram replaced "host-to-host" for the transport layer with "process-to-process" and there was determined argument that host-to-host was wrong. The position now seems to be reversed and you are agreeing that "host-to-host" was correct?

Regarding the above, of course TCP offers process-to-process communication but the diagram shows data flow (see my earlier message). The data flow for TCP is the stuff in the TCP header and that is host-to-host communication—the sending operating system and the receiving operating system communicate to ensure (if possible) that an error-free stream of information at the application layer is received, without duplication. Your proposals do not make sense. Johnuniq (talk) 02:05, 19 July 2018 (UTC)

Please read what I wrote above. I'm not talking about the diagram (which started this but is actually a secondary issue). Yes, TCP is a host-to-host protocol. TCP offers process-to-process (end-to-end, application-to-application) connectivity and services, which needs to be explained prominently. Host-to-host connectivity is offered by IP. JensLechtenboerger (talk) 05:46, 19 July 2018 (UTC)

I know you are not talking about the diagram. I mentioned it to show that your comments seem to be all over the place. First it was impossible for TCP to be host-to-host. Now it is totally natural and no one should mention the previous discussion. This issue cannot advance until you engage with the issues raised (hint: see "data flow" and "TCP header"). A piece of wire offers host-to-host connectivity but we don't elevate that to "host-to-host communication" because there is no stateful communication involved. Johnuniq (talk) 06:03, 19 July 2018 (UTC)

I believe that the discussion on the diagram arrived at a dead end. So my aim was to open a self-contained discussion about what I now (after the above discussion) believe to be the core issue with the article. (Actually, on 07:37, 11 July 2018 Johnuniq pointed to contradictions between my diagram and the article as reason to reject the diagram. Now, I'm trying to address the article first.) I don't see an issue with "data flow." Neither the article nor RFC 1122 mention it at all. RFC 793 contains this: "Various levels of protocols in the networks, the gateways, and the hosts support an interprocess communication system that provides two-way data flow on logical connections between process ports." I'm fine with that. I'm not sure how "stateful" is related to our discussion. My point is that TCP (and, of course, also UDP as another transport layer protocol) offers process-to-process services. Yes, TCP maintains state, whose relevance for our discussion I do not see, though: RFC 768, specifying UDP, does not contain the string "state" at all. JensLechtenboerger (talk) 13:45, 19 July 2018 (UTC)

This is getting into the ridiculous. Indeed JensLechtenboerger's arguments are all over the place, in search for straws to support some meaning that is now not even consistent. Now the argument is not about the diagram anymore ? What else? If you want to provide a meaning to the terms host-to-host, end-to-end, application-to-application, process-to-process, then you need to have very definitive criteria for them. The fact is that these are not defined terms in the Internet Protocol Suite. They are used to characterize the encapsulation hierarchy of the protocol stack, and thereby the operating scope of its layers. As the article stands it is consistent with the spirit of the history of development in the IETF. If you don't understand it, then don't change the article. Kbrose (talk) 13:37, 19 July 2018 (UTC)p

In resonse to Johnuniq I just clarified my reasons for proceeding this way. The fact that TCP is called host-to-host protocol while it provides process-to-process services is a source of confusion, but that is not my fault. Except for that, what is not even consistent? Besides, arguing with the "spirit of the history of development" here will not help any reader. JensLechtenboerger (talk) 13:56, 19 July 2018 (UTC)

"while it provides process-to-process services" appears to be incorrect. See section below. --Guy Macon (talk) 22:15, 19 July 2018 (UTC)

You are right, TCP can be used without processes (I also responded below). Do you agree that TCP supports full-duplex byte streams for lots of "active parties" (processes, applications) on one host (which may not be a general purpose computer) so that they can communicate with other active parties on other hosts? JensLechtenboerger (talk) 08:37, 20 July 2018 (UTC)

TCP is host-to-host, as someone (and only one) has to be able to acknowledge packets. You can't use TCP in a broadcast sense. UDP, on the other hand, can be broadcast. Gah4 (talk) 09:16, 21 July 2018 (UTC)

I'm sorry for my sloppy wording. I did not want to open a discussion about broad- or multicasting. Below, Guy Macon led me to the conclusion that the more general term "application" should be preferred over "process." Anyways, there can be multiple applications per host (using TCP and acknowledgments as well as UDP without them), for which TCP and UDP provide end-to-end communication services. JensLechtenboerger (talk) 14:58, 21 July 2018 (UTC)

I might have known at the time that it wasn't multicasting that you wanted to discuss, but I do think it is an important distinction that a TCP connection always has two ends. (Or one, before the connection is made.) Where UDP can have more than two. Otherwise, in multitasking systems, TCP connections are usually handled by the OS, where in single task systems, they tend to be done by the actual user program. For MS-DOS and older MacOS, there are programs that directly talk to the NIC with no OS help. (Because the OS didn't know about IP at all.) Gah4 (talk) 19:03, 21 July 2018 (UTC)

The presentation of the transport layer affects how neighbouring layers can be described. I disagree with the following under “Architectural Principles” and propose to use RFC 1122 as reliable source in each case:

Application layer: I disagree with: “The application layer is the scope within which applications create user data and communicate this data to other applications on another or the same host.” Applications create data but communication of that data is handled by protocols at lower layers, not the application layer. I also disagree with: “Processes are addressed via ports which essentially represent services.” Ports are a transport layer concept, not application layer. I propose to start with this quotation from RFC 1122: “The application layer is the top layer of the Internet protocol suite.”

Transport layer: See proposal above (14:43, 18 July 2018), however, preferring “application” over “process.”

Internet layer: Currently, the focus is on next hop routing, which is not incorrect but misses to clarify the host-to-host purpose. I propose to start with this sentence from RFC 1122: “All Internet transport protocols use the Internet Protocol (IP) to carry data from source host to destination host.”

Of course, those changes also need to be reflected in the Introduction, where each layer is summarized by a few words. Consensus or dispute? JensLechtenboerger (talk) 17:55, 22 July 2018 (UTC)

I agree with everything but "Applications create data but communication of that data is handled by protocols at lower layers, not the application layer." Each layer "communicates" with its counterpart on the other side, including the application layer. "Communicate" is a matter of perspective – the actual movement of data only happens on layer 1. All the other layers communicate as well but each in a different way and each using the next lower layer for service. --Zac67 (talk) 18:11, 22 July 2018 (UTC)

I agree. In my view, the current wording "applications create user data and communicate this data to other applications" is misleading. What about adding "—by using services of lower layers—" before "communicate"? JensLechtenboerger (talk) 14:19, 23 July 2018 (UTC)

The above changes are applied. Potential for changes in that spirit remains in subsections of "Key architectural principles." JensLechtenboerger (talk) 14:26, 27 July 2018 (UTC)

Concerning the notion of host-to-host protocol, I came across this quotation dating back to 1977, IEN 12: "The need for a protocol that supports distributed process-to-process communication was realized early by ARPA network designers and the ARPA host-to-host protocol (AHHP) became the reference point for such process-to-process protocols." In my view, this quotation shows that we need to be very careful when using the term "host-to-host" (if at all). JensLechtenboerger (talk) 10:06, 7 August 2018 (UTC)

There is nothing mysterious about "host to host" in the context of TCP/IP. It just refers to how the operating systems on two computers cooperate to exchange information. The hosts are not doing that for their own benefit, they are doing it as requested by processes. The processes engage in process-to-process communication using the host-to-host link established by the operating systems. That's it. Reading Host (network) might be helpful. Johnuniq (talk) 11:10, 7 August 2018 (UTC)

It's the same argument as before. The facts are that TCP uses IP's host-to-host transport service and TCP provides a process-to-process communication channel. This is what I called the "lower interface" towards IP and the "upper interface" towards the application protocol before. Stating that TCP is a host-to-host protocol isn't wrong but it's highly misleading, especially for beginners. --Zac67 (talk) 15:22, 7 August 2018 (UTC)

The reason for the confusion, and a suggested way forward

Consider the turn signal on my Subaru. Is it an example of vehicle to vehicle communication? Sometimes yes, sometimes no. I actually own two Subarus, one new and one from 1998. When the new subaru signals a turn, the signal goes to eyes of the driver of the old; the vehicle has no sensor for that. The opposite is not true; the new subaru has a vision system that, among other things, detects brake lights and turn signals when deciding when to apply automatic braking and lane assist.

So. is a turn signal an example of driver to driver communication? Yes, but that's not all it is. Besides telling driver (and maybe a vision system) that I intend to turn, it also signal pedestrians.

And my turn signal is also involved in communication between processes running on my car. There is a process that alerts me if I am drifting out of my lane and which turns the steering wheel to keep me in the lane. That process gets a signal from the turn signal process and allows lane changes that I signal. This is normally through a CAN Bus.

Well at least we can assume that a turn signal involves a flashing light (the physical layer), right? Nope. I can ride a bicycle and use hand signals.

Computers have the same problem with overlapping definitions. Normally processes communicate as described in Computer multitasking, but they can communicate through TCP/IP, through a turn signal being detected by a vision system, or through the US Mail.

And sometimes there is no process, no operating system, and no computer. I can design a system that implements layers one through five and part of layer six using a state machine running on a FPGA -- no OS, no stored program, no computer.

There are a bunch of ways to describe all of this, but in the context of the Internet protocol suite we use the OSI model.

OSI Model
Abstraction layer		Protocol data unit	Function
Host layers	7. Application	Data	High-level APIs, including resource sharing, remote file access
	6. Presentation		Translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption
	5. Session		Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes
	4. Transport	Segment, Datagram	Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing
Media layers	3. Network	Packet	Structuring and managing a multi-node network, including addressing, routing and traffic control
	2. Data link	Frame	Reliable transmission of data frames between two nodes connected by a physical layer
	1. Physical	Symbol	Transmission and reception of raw bit streams over a physical medium

So none of the "IP stack connections diagram" images above are correct in this context. the dotted lines shouldn't be there, all seven OSI layers should be shown, and they should be called exactly what they are called in the table above.

--Guy Macon (talk) 14:24, 19 July 2018 (UTC)

Thanks for sharing this view. Yes, TCP/IP can also be used in environments without any notion of process at all. Nevertheless, RFC 793 presents TCP as protocol that offers process-to-process connectivity.

That FPGA device of yours, for what might it be good? Would you agree that its TCP implementation is useful to support one or more applications (avoiding the term “process”) in their communication? JensLechtenboerger (talk) 08:28, 20 July 2018 (UTC)

RFC 793 was published in 1981. The OSI model was published in 1984. I know of no post-1984 RFC that uses the "process-to-process" language. RFC 1180[1] is a good example of current (1991, actually) usage.

Here is the kind of thing that you can do with FPGAs:[2][3][4] For convenience, there is usually an ARM Cortex M1 programmed into the FPGA, but the actual handling of very high speed data is way beyond what any microprocessor can handle, and is instead done in hardware. --Guy Macon (talk) 09:48, 20 July 2018 (UTC)

Thanks for the pointers. With my questions I was hoping for preferred wording concerning the active things that use Transport layer services. Indeed, RFC 1122 and RFC 1180 use “application.” I do not believe that my statements are invalidated by replacing “process” with the broader term “application.”

Actually, my proposal for a change of the article (as of 14:43, 18 July 2018) still remains valid: Replace the beginning of the sentence “The transport layer performs host-to-host communications...” with this quotation from RFC 1122: “The transport layer provides end-to-end communication services for applications...” JensLechtenboerger (talk) 14:22, 20 July 2018 (UTC)

I agree. "Application" is a better fit with the OSI Model. --Guy Macon (talk) 15:39, 20 July 2018 (UTC)

Why do you suggest to explain the Internet protocol suite based on the OSI model? Would OSI layers 1, 5, 6 not distract readers? (There is a section "Comparison of TCP/IP and OSI layering," which could benefit from the OSI diagram and which is in need of reliable sources.)

What I really like about the diagram in question is that it shows Internet layer connectivity from source host to destination host via a sequence of next-hop routers (which do not worry about higher layers). In response to this discussion, I changed "process-to-process" to wording from RFC 1122 in my version of the diagram. Personally, in class I use the dashed lines to explain process-to-process communication via TCP, so I will not delete them. JensLechtenboerger (talk) 10:20, 21 July 2018 (UTC)

I don't make a big deal about any minor disagreements I have with someone who is doing a good job maintaining an article, so do it however you see fit. That being said, my advice is to describe everything according to the OSI model, using the exact terms used in the OSI model. I think that it will reduce confusion for readers who read several related articles if they see see them all using the same words for things. --Guy Macon (talk) 19:21, 21 July 2018 (UTC)

If you remember that the 7 layers is a compromise between 6 and 8, you might realize not to take the details too closely. The lower levels usually come out pretty close, higher not so close. (Along with the 48 bit ATM payload, a compromise between 32 and 64.) Gah4 (talk) 21:06, 21 July 2018 (UTC)

References

The recent version X.200 7/94 can be download directly from ITU-T – however, there are some differences between the OSI and the DoD models, and this dispute is about the transport layer in the DoD model. Additionally, the OSI definitions are very abstract and not trivial to match. --Zac67 (talk) 22:15, 21 July 2018 (UTC)

@Guy Macon: I’m not sure whom you address here. My familiarity with inner workings of Wikipedia editing is pretty low. I do not check whether there are individuals “maintaining” articles, but just edit. I do not know when disagreement is “minor” or not. My experience here tells me that I might never be able to predict that. Also, if this article gets improved, maybe related articles can also benefit. Does that imply that I should first figure out what articles might be related before editing here? Anyway, in the above section about a dispute that I perceive, I’ll add more concerns as the presentation of the transport layer affects the neighbouring layers as well. JensLechtenboerger (talk) 17:36, 22 July 2018 (UTC)

What I was trying to convey is this:

[1] I think you are doing a great job. Wikipedia needs more editors like you. Same for the others who have recently edited this page; other than the usual vandals, I think everyone is working to make the article better.

[2] Although I do have some expertise regarding various Internet protocols, I don't expect to be edit any articles on them any time soon (I am here because I was asked[5]), preferring to focus on microcontrollers.

[3] I just wanted to post my (hopefully informed) opinion here and then let those who are more interested in this topic decide what to do. I am fine with whatever decision is made. --Guy Macon (talk) 19:58, 22 July 2018 (UTC)

I’ve come to agree with Guy Macon: The "IP stack connections" diagrams should not include the dashed horizontal lines. Each protocol comes with two interfaces, the service interface specifying the purpose of the protocol (what it offers to higher levels) and the peer interface specifying how the protocol is implemented. My current understanding is that each diagram implicitly focuses on another interface. Without further explanations, both diagram versions can be misread easily as our discussion shows. JensLechtenboerger (talk) 17:29, 22 July 2018 (UTC)

I thought we'd use the talk page to discuss upcoming changes. Apparently, that's wrong. On 16:00, 15 August 2018‎, I edited the article to show a version of the diagram without dashed lines as proposed here. That was reverted, noting the importance of dashed lines. In fact, I agree that the lines are important, but I disagree with the current version's labels "process-to-process" and "host-to-host": First, as discussed also on this talk page (maybe also without consensus?), "application" is preferable to "process." Second, the transport layer provides application-to-application data flow. Third, "host-to-host" is not explained in Wikipedia. Fourth, the IP provides host-to-host data flow, not the transport layer. Consequently, I'll replace the current diagram version with my version with changed labels, which fit the article's descriptions. If that gets reverted, I'll add a disputed tag. JensLechtenboerger (talk) 07:58, 17 August 2018 (UTC)

A reasonable position would be to say that "process" is the correct word but "application" is more accessible for a general audience. Suggesting that "process" is somehow wrong indicates a lack of familiarity with technical details. This discussion is irritating because there is no engagement with the core message of earlier comments. I explained the situation above, for example at 09:30, 11 July 2018 and I provided an authoritative reference in the Craig Hunt book. Johnuniq (talk) 09:48, 17 August 2018 (UTC)

generalization

There is the old quote All generalizations are false, including this one. Seems to me that much of this discussion is on generalizing the design and layers of networking protocols, and those might work most of the time, but not all. For one, the OS kernel might be the endpoint of some communications, but there are worse problems. There are redundancy systems that allow more than one host to process data, such that even the host-to-host generalization is wrong. There is broadcast (for UDP but not TCP) which allows one-to-many communications. Gah4 (talk) 00:58, 31 August 2018 (UTC)

Deleted ref

[6] was used as a ref in Internet protocol suite#Internet layer. It was commented out, "Now a nasty spam link. no archive available." Here is an archive. The ref does not support the material in the section so I have deleted it. ~Kvng (talk) 14:32, 30 March 2020 (UTC)

Non-standard caps

Previous discussion established a convention of capitalizing only the first word: Internet protocol suite. This is at odds with MOS:CAPS where a topic is either a proper noun or it isn't and is presented in title case or lowercase respectively. What we're presenting here is neither. ~Kvng (talk) 15:31, 23 January 2021 (UTC)

Lack of References

Many claims don't have references. For example, see the claim on QUIC. — Preceding unsigned comment added by 49.207.217.151 (talk) 04:58, 5 June 2022 (UTC)

You might want to add {{Citation needed}} after the claims in question, to make it more obvious which ones need work. Guy Harris (talk) 06:07, 5 June 2022 (UTC)

Layer names and number of layers in the literature (removed section from article)

I removed the following section because it seemed more confusing than helpful; if you're in a position to explain the relationship between the different models and the Internet protocol suite, and decide which actually belong here, feel free to add it back in. Rusalkii (talk) 19:59, 26 October 2022 (UTC)

I am inclined to restore this immediately. It seems a personal aversion to complexity, and complex the history of these protocol suites has been. The table is clearly relevant, as the core of the Internet Protocol Suite is often misrepresented by people trying to merge or squeeze it into other models, mostly related to the OSI model. The table also shows some historical progression of thinking, when shown next to the ARPA model. I do agree that the prose around the table should be improved to provide better context. kbrose (talk) 23:37, 26 October 2022 (UTC)

I don't mind the complexity, but presented without context I went down a half-hour rabbit hole trying to even figure out which of these was the internet protocol suite the article is about. I think the table would be very useful with context and worse than useless without it, and I don't yet know enough to add the necessary context. I might try to work on this section this weekend but I likely won't have the time. Rusalkii (talk) 23:31, 27 October 2022 (UTC)

trying to even figure out which of these was the internet protocol suite the article is about None of them are. Column 1 is the OSI model, and columns 2-N show mappings between layers in various models developed for the Internet protocol stack to the OSI model. If there were a separate page for those models, separate for the page for the protocols - as there once was - this table would belong there, not here Guy Harris (talk) 02:23, 28 October 2022 (UTC)

Restore – Those are the most common layering models that you run across in various standards or literature. The table may be very helpful for anyone trying to correlate those sources. I don't see anything confusing with that. --Zac67 (talk) 05:54, 27 October 2022 (UTC)

@Kbrose: Good job! @all We should also consider reordering the table columns, so the more important ones are on the left. The imho most significant are RFC1122 (topic) and OSI, with Cisco, Tanenbaum and Kurose behind that. Where should be put RFC871 (historical)? --Zac67 (talk) 19:29, 28 October 2022 (UTC)

I would think the sequence is okay, if the OSI column in first position is moved to the last position. OSI should not be in the middle somewhere, because it is the most detailed and least congruous. At the end it provides the comparison to that world, to which the text book authors do not belong. kbrose (talk) 18:36, 29 October 2022 (UTC)

Layer names and number of layers in the literature

The following table shows various networking models. The number of layers varies between three and seven.

OSI model (ISO/IEC 7498-1:1994)	Arpanet Reference Model (RFC 871)	Internet Standard (RFC 1122)	Internet model (Cisco Academy)	TCP/IP 5-layer reference model (Kozierok, Comer)	TCP/IP 5-layer reference model (Tanenbaum)	TCP/IP protocol suite or Five-layer Internet model (Forouzan, Kurose)	TCP/IP model (Stallings)
Seven layers	Three layers	Four layers	Four layers	Four+one layers	Five layers	Five layers	Five layers
Application	Application/Process	Application	Application	Application	Application	Application	Application
Presentation
Session
Transport	Host-to-host	Transport	Transport	Transport	Transport	Transport	Host-to-host or transport
Network		Internet	Internetwork	Internet	Internet	Network	Internet
Data link	Network interface	Link	Network interface	Data link (Network interface)	Data link	Data link	Network access
Physical	—	—	—	(Hardware)	Physical	Physical	Physical

Some of the networking models are from textbooks, which are secondary sources that may conflict with the intent of RFC 1122 and other IETF primary sources.

References