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)