Talk:Internet protocol suite/Archive 1

Archive 1

Archive 2

Archive 3

Confusion between IP and TCP/IP

This page needs to be edited to remove confusion between IP and TCP/IP. It should probably be renamed IP and information specific to TCP moved to a separate page. Remember that TCP and IP are separate protocols, and that you can run things other than TCP over IP (e.g. UDP and ICMP) and that you can at least in theory run TCP over protocols other than IP. -- poslfit

There is already an article on IP called Internet Protocol. If you want to rearrange things more logically you are free to do so. --Zundark, 2002 Jan 5

Thanks, I'll work on it -- poslfit

Why 7 layers?

Why are there 7 layers in the stack? I thought that TCP/IP only had 5.

5. Application - DNS, HTTP, FTP, Telnet, etc.
4. Transport - TCP, UDP
3. Network - IP
2. LAN/Link - network address (physical or MAC)
1. Physical - low-level signal

—64.247.79.58 (talk • contribs) 03:48, 8 June 2003.

TCP is best looked at is 5 layers but some companies such as cisco try and shoehorn it into the OSI 7 layer model Plugwash 20:10, 22 September 2005 (UTC)

Why 5 Layers?

http://de.wikipedia.org/wiki/TCP/IP has only 4 and all they teach us at university is that there are only 4 layers! layer 1 and 2 is merged. Please discuss.

The more i think about this the the more i've come to realise that fixed layer models just don't fit real networks very well. TCP/IP iteself has two layers IP and TCP/UDP/ICMP/...... . Below theese there may be an arbitary number of layers specific to the network type and above theese there may be an arbitary number of layers specific to the application. -Plugwash (talk • contribs) 16:10, 8 May 2007 (UTC).

You're absolutely right. There's a good discussion of the role of layers in the textbook "Computer Networks" by Peterson and Davie, Section 1.3, where they first introduce the idea of layering, then treat the OSI and Internet architectures as two instances of layering (the different ways of layering define different architectures; there are additional issues to defining the architecture, like how the layers interact). The two different stacks of layers can indeed be sort of matched up to each other - but neither of them totally explains the reality of network protocols, since many actual protocols violate the layering sometimes. You could think of layering as a way of breaking a monolithic network protocol, which provides all the functions required for communication, into components, just as you create modules to break a program into components. As with programs, there's not just one way of doing it, the best way of doing it varies with the context. Since protocols have to solve the same problems over and over, and you'd like to break them apart so you don't have to re-write the same piece over and over, so you end up with layers (a good summary of Internet layering is above). Ngriffeth 19:08, 2 July 2007 (UTC)

Check this out. It explains the varius layers and compares the 7 layer model to the 5. [1] Tmchk | Talk 09:49, 5 August 2007 (UTC)

Layering, as an abstraction, is useful up to a point. It can be overused.

I have insufficient hair to tear it out whenever I try to explain that the Internet protocol suite was not intended to match OSI, was developed before OSI, the full set of OSI specifications (i.e., not just document ISO 7498) subdivide layers so that it is no longer seven, and that OSI has, in the real world, been relegated to a teaching tool. The Internet Protocol Suite has four layers, defined in http://www.isi.edu/in-notes/rfc1122.txt, and no IETF document, as opposed to some nonauthoritative textbooks, say it has five.

Unfortunately not available free online AFAIK, there are ISO documents such as "Internal Organization of the Network Layer", which splits the network layer nicely into three levels, logical (lower-layer agnostic), subnetwork (i.e., link technology) specific, and a mapping sublayer between them. ARP, with which many people struggle, drops perfectly into the mapping (technically subnetwork dependence convergence) between them. Another ISO document, "OSI Routeing [sic] Framework", makes it clear that routing protocols, no matter what protocol carries their payloads, are layer management protocols for the network layer. Annex 4 to ISO 7498 gives the OSI Management Framework, with both system management and layer management components.

When the IETF was dealing with MPLS and some other things that "don't quite fit", and some people insisted on calling it "layer 2.5", the reality is that the IETF set up a "Sub-IP Area" and did the original work there. MPLS is now back under the Routing Area. There was also a Performance Implications of Link Characteristics (PILC) working group that has ended its effort, but also deals with sub-IP (archives at http://www.isi.edu/pilc/).

After I do some drawings, I'll put more detail of this on my user page. Howard C. Berkowitz 18:54, 15 September 2007 (UTC)

Confusing layers

When I think about it, I think ICMP is on the same layer as those too .. IGMP I know nothing about, though. --Wikipedians/arcade

Yes, that's right: Even although ICMP is a required protocol for the TCP/IP stack, it is still implemented as a Transport layer protocol, not as a Network layer protocol. This can be easily seen by the fact that ICMP has a protocol number (it being protocol number 1). The same is true for IGMP (except that it has protocol number 2).

In fact, there is only one network layer protocol in the TCP/IP stack: IP itself. -- Wouter Verhelst 12:42, 9 February 2004

Hmm, when I think a bit more about it. The Internet Protocol Suite doesn't follow the OSI layering all the way, so the stack is quite simply ... wrong, as it is portrayed.

The 3 bottom layers are pretty okay. However, IMCP is dependent on IP, so it needs to be pushed higher up on the stack. HTTP/STMP/SNMP and so forth are _NOT_ dependent on the layer that is presented as beneath it, and thus needs to be bumped down.

Roughly, something like:

7. Protocols that are tunnelled through those in layer 6. Say an XML protocol served through a HTTP server.
6. HTTP/SMTP/SNMP/FTP/and-so-forth
5. TCP/UDP/ICMP/Whatever
4. Transport (IP, for the internet protocol)
3. Network
2. Data Link
1. Physical

--Wikipedians/arcade

No, you're applying the OSI network concept to the TCP/IP network stack. That isn't correct. -- Wouter Verhelst 12:42, 9 February 2004

No, OSI/ISO is the standard, so applying it is standard when talking about TCP/IP layers. What they say goes, they say seven, then there are seven.

Not sure about that... How about:

=> Application (telnet, ftp, http, dns, ...)
4. Transport (TCP, UDP...)
3. Network (IP)
2. Data Link (Ethernet, Token-ring, ISDN...)
1. Physical

Labelling formats like JPEG (or EBCDIC / ASCII) as a presentation layer is a bit of a hack to force the square peg of real world networking into the round hole of OSI protocol stackery (IMHO, of course).

Sometimes the Application Layer is still called layer 7 for "compatibility", but there is no real unified layer 5 or 6 -- sessions, presentation and data formats are considered the task of applications, and are absolutely not part of the TCP/IP protocol suite. --Paul 16:28, 23 July 2003

ICMP is definitely not part of the transport layer. Layers in the OSI model are defined by functionality, not by dependencies between protocols (think modules). Layer != Protocol! So everything which is related to getting packets from one host to another is logically part of the Network layer. That includes routing - which in at least one case has a protocol (BGP) runs on top of TCP (which is at the transport layer)! Look, I know this all seems totally crazed - it is totally crazed. The ISO model has only limited usefulness. It divides things up into functional layers, it is not a module dependency diagram.

It's for these reasons that I removed ICMP from Template:IPstack. It was at the wrong layer, and since it is such a confusing case, it seemed better not to include any of these confusing cases in the diagram. Noel 13:02, 14 Sep 2004 (UTC)

I think the German suite diagram clears up some of these confusing elements. Also, following some of the protocol links like de:HTTP shows the implementation dependencies via another diagram. Dols 13:04, 2004 Oct 6 (UTC)

I don't understand this comment. I looked at the pages you mention, and their diagrams look pretty much identical to Template:IPstack, except that it has a few more protocols. Noel (talk) 05:33, 16 Dec 2004 (UTC)

Back in October the diagram looked different. http://de.wikipedia.org/w/wiki.phtml?title=TCP/IP-Referenzmodell&oldid=2921843 I'll try to stop adding confusion into the confusing layers discussion. Dols 00:01, 2004 Dec 18 (UTC)

Ooops! My fault for coming by and adding a comment so much later! Yes, now I understand your comment.

Still, the old version (the one you linked to above) of the diagram has many of the problems I mentioned above - e.g. it lists BGP as being at the application layer (yes, I know it uses TCP, but...) and also DNS as an application (Email and HTTP will be astonished to hear that), shows ICMP as a tranport protocol (it's entirely part of the internet layer), etc. Noel (talk) 00:57, 18 Dec 2004 (UTC)

Yes, BGP should be listed at the application layer. Just because it often alters the information that is used to make decision on layer 3 it doesn't have to (think of a route-server) and so it really is just another protocol running over TCP. It should definitely be listed as an application layer protocol. Can we please change this? (Same goes for RIP) Kll (talk) 07:26, 1 August 2008 (UTC)

Perhaps we could change the text to read "It is now described using the concept of five layers as technology has changed." instead of "it has evolved into five layers". I think the important part to to inform the reader that "layer" is a concept, not a thing, and thus our understanding of it may change without a physical change. Tmchk | Talk 09:19, 5 August 2007 (UTC)

OSI was practical

Can't agree with "The Internet model was produced as the solution to a practical engineering problem. The OSI model, on the other hand, was a more theoretical approach."

Internet architecture developed as a means of internetworking on a "non-sectarian" basis-- a practical engineering problem.

The OSI Reference Model likewise developed as a means for networking systems on a "non-sectarian" basis. More specifically, there was a clear understanding at the time that the goal was to interconnect computers and/or devices in a way that did not depend on IBM intellectual property. Witness the striking similarities between the OSI Reference Model and IBM's SNA. Anyone working for DEC or NEC or HP or Siemens or the like at the time will assure you it was a VERY practical engineering problem.

OSI protocols became ungainly and arcance in toto not because the work was theoretical but because the work was done in government-entangled standards bodies. Anyone familiar with the total output of the internet community knows it's output is likewise full of a lot of unused junk and nonsense besides the successful and critical parts, regardless of it's requirement for "working code". —The preceding unsigned comment was added by 172.208.215.173 (talk • contribs) 05:43, 27 December 2003.

This, in my ever-so-humble opinion, is a load of hooey. As even a brief googling can show (e.g. [2]), it was intended as a research effort - and its myriad layers were there from the start, not due to standards bodies' meddling. --moof 00:37, 29 October 2005 (UTC)

IPstack

Guys, can anyone tell me how the {{IPstack}} tag works, where it is defined and how to edit it? Thanks. Sridev 13:48, 25 Sep 2004 (UTC)

It's at Template:IPstack. The way it works is that when the page-rendering code reads the {{IPstack}}, it replaces it with the contents of the Template:IPstack page. May I suggest you mention your proposed change(s) at Template_talk:IPstack first? Thanks... Noel (talk) 05:14, 16 Dec 2004 (UTC)

Rwin

(This seems like a logical place, but I'm not quite sure where it should be...)

There is a stub article, Rwin, in which I added some things.

I am recommending that a link be created from this article to the Rwin stub, even if the link does not fit with this article. The reason being is, it was quite difficult to navigate to the Rwin article without seraching. For someone who is looking for information about how to tweak their TCP/IP settings but does not know to search for the term 'Rwin' etc. to learn more, they might be kind of lost. Either way, I tried to find the information. I did find it after a while, but I already knew about the term 'rwin'.

I also created a redirect from Tcp receive window and TCP Receive Window to Rwin because that was what I was using for my search terms. I could only find the rwin article by using 'rwin' as my search term.

If anyone here is considered to be a network guru, the Rwin article is looking for an expert.

Is there an article in Wikipedia which talks about tweaking the stack? TCP/IP Tweaks maybe? I have yet to find one. -- After much reading and searching, I finally found the article that I was seeking at first, TCP tuning. However, it didn't have the information that I added to Rwin. I'll let someone who actually knows where things are supposed to be, arrange the information accordingly.

I strongly suggest that a link about tuning/tweaking and rwin as a sub-heading, be placed in the table of contents of the article page (for this article).

Somewhat related:

If anyone would like to help me tweak this article, I would appreciate it.

Wisepiglet 05:03, 7 December 2006 (UTC)

Readings typo

Surely we can recommend additional readings besides a MS Windows 2003 book?

In any event, the citation contained 2 typos: The corrected version appears below

Davies, Joseph and Lee, Thomas. (2003). Microsoft® Windows® Server 2003 TCP/IP Protocols and Services Technical Reference. Microsoft Press, Redmond Washington, USA.

Hopefully these corrections will also eventually filter down to derivitive sites such as: http://www.domainsarefree.com/glossary/Internet_protocol_suite.html (They also need to change their character set from utf-8 to iso-8859-1 so the ® marks render properly.) —The preceding unsigned comment was added by 65.88.178.10 (talk • contribs) 19:30, 4 November 2004.

Wish granted. Replaced book list with more representative "classic" titles. - Dmeranda 05:10, 23 Nov 2004 (UTC)

Some Clarification

The reference above stating there are only four layers in the TCP/IP model is accurate. The "Host-to-network" layer is often refered to as the Network Access layer. The TCP/IP model has no Physical layer because LAN and WAN protocols operate partly at the OSI Physical layer and partly at the IEEE 802.3 Media Access Control (MAC) sublayer of the OSI Data Link layer. The TCP/IP model was designed to be completely independent of the LAN/WAN protocol frames that encapsulate IP packets. Thus, an IP packet can be encapsulated in an Ethernet frame, a Token Ring frame, or any other type of frame, and the IP packet is not changed, nor is the function of the TCP protocol affected in any way. By extension, the TCP segment encapsulated inside the IP packet is not changed either.

The upper half of the OSI Data Link layer, the IEEE Logical Link Control (LLC) sublayer, can be said to loosely correspond to the TCP/IP Network Access layer. The lower half of the OSI Data Link layer, the IEEE MAC sublayer, and the OSI Physical layer, can only be said to correspond to the TCP/IP Network Access layer in a general sense. The Network Access layer is necessary to allow an IP packet to make a physical link to the network media. Generally, this is done by maping IP addresses to physical hardware addresses and encapsulating IP packets into frames. The physical media connection is defined based on the hardware type and network interface, as well as the LAN/WAN protocol in use. Jim Elms, CCNA, CCAI 05:55, 24 December 2004

It's true that in some rough sense, the IP model has only 4 layers (particular network, internetwork, transport and application), but that's only in a rough sense.

For one thing, in understanding the particular network at hand, that network is usually structured as a series of layers - at least 2, and in some cases more. E.g for 802.* networks, there's a physical layer (what voltage correspond to 1 and 0, bit rate) which differs from technology to technology, as well as framing layer (what a packet looks like), and some of them have a (third) MAC layer as well. ATM is another good example; above the physical layer, and the framing layer, there are protocols (AAL is their name, IIRC) for breaking up a large packet into 48-byte chunks, other protocols for setting up PVC's, etc.

And then there's MPLS, which is its own little complication - since it is intended to carry a packet across multiple networks, its an internetworking protocol, but it's below IP...

The second way in which that 4-layer model is only roughly correc is that IP is starting to use more than 1 layer above the transport. A good example doesn't come to mind off the top of my head, but if e.g. some application uses a standard remote procedure call protocol on top of TCP, then there are two layers on top of the application. One might view both email (822 header and SMTP) and the web (HTML and HTTP) as having several layers. Etc, etc... Noel (talk) 12:58, 22 September 2005 (UTC)

It would be great...

It would be great if this article had some practical info. I'm currently struggling with TCP/IP settings. Chamaeleon 18:04, 2 Mar 2005 (UTC)

This is an encyclopaedia, not a "how to" manual. Noel (talk) 12:58, 22 September 2005 (UTC)

Regardless, practical info is a good way to relate technical content. Chamaeleon, what would you like to see added that isn't in the land of tutorials? Cburnett 02:44, 6 March 2006 (UTC)

MPLS

Not really sure where MPLS fits into this picture. From ISO Model Talk I Wrote:

MPLS is considerd to be a switching techonology, i.e. layer 2. However it runs on other layer 2 technologies such as Ethernet or ATM, then why is it not considerd layer 3. Then again is what defines a layer 2 Protocol one that specifies the next hop in the path while layer 3 specifies the final destination.

Possibily could MPLS be considerd a sub-layer of Layer 2, so if MPLS ran over Ethernet there would be 3 sub-layers LLC layer, MAC layer and MPLS layer. Vec 19 April 2005

MPLS is definitely a layer-3 protocol; in fact, it's actually an "internetwork layer" protocol - albeit a lower-sublayer of the internetwork layer, underneath IP, etc. That's because MPLS is used (potentially) to deliver a packet across multiple networks, so it's inherently an internetworking protocol. Noel (talk) 19:35, 14 September 2005 (UTC)

Some consider MPLS to be layer '2.5' - mostly because it contains hints to the layer 2 fabric while remaining primarily level 3.

List of common ports

I was just skimming this article, and as I got near the bottom found my screen filled with the list of port numbers; it rather surprised me. Now, firstly, do we need this list at all? We already have a List of well-known ports (computing), which is naturally more comprehensive, and port numbers aren't directly relevant to this article. And secondly, if it is kept, it should be pruned mercilessly (why, for instance, is QOTD mentionned in such a short list?) and formatted to take up less space (while the number-in-a-square trick looks kinda cool, its main effect is to spread the list right down the page; ugly). Anyone any thoughts? - IMSoP 20:32, 2 August 2005 (UTC)

I say remove the whole list. Port numbers are useless without specifying TCP or UDP. And QOTD and gopher hardly belong in such a short list. Rather than redo it to include TCP/UDP, I say just provide a link to the main article listing well-known ports. Pfalstad 18:33, 3 August 2005 (UTC)

Take OSI Out (of the top area)

Sorry to re-open the layers issue, but I have a real problem with the page as it stands. When I click on "Internet protocol suite", one of the first things I would expect to find would be a (rough) diagram of the IP/etc stack, showing how things relate to each other. What do I actually find? The first diagram is of the OSI stack, with IP-related protocols jammed into the OSI layers.

Now, if the IP stack was even attempting to be an implementation of the OSI model, this would be valid -- but it isn't! IP follows its own model, which is not the OSI model. The IP layers do not map onto OSI layers (exactly). So, for the discussion to begin with "IP in terms of OSI" is, in my opinion, just plain wrong, as well as misleading. My feeling is that the whole "Layers in the TCP/IP stack" section should not even mention OSI, as it's not really relevant -- IP is IP, not OSI. The "Layers" section should be rewritten in terms of IP/etc. alone, and with a nice diagram showing how the bits relate. I'm thinking of something along the lines of the old German suite diagram, maybe enhanced to include more stuff. I like it because it doesn't just arbitrarily split things into layers; it shows how things actually relate to each other, and how some things (eg. ARP) span layers, which is closer to the truth.

Now, clearly there is some correspondence between the IP stack and the OSI stack, and the OSI stack is often presented as an "idealised" networking model in textbooks etc. (regardless of how valid this may be). So, I think a later section titled something like "The IP Suite as it relates to OSI" would be appropriate for that material; maybe after the "Development" section. I think this should include virtually all of the current "Layers in the TCP/IP stack" section.

So any comments? I'll go ahead and do it if there are no objections. -- Johantheghost

Objection from me. TCP/IP is commonly taught using the OSI layers. My University taught it as such (Oxford Brookes), and Cisco's certification process teaches it as such. It may not have been originaly developed as an OSI model network, but it has served very well to describe it within that model. To quote Tanenbaum in Computer Networks, pp44 third international edition, on his choice to teach with a OSI Hybrid model, "In Summary, despite its problems, the OSI model (minus the session and presentation layers) has proven to be exceptionaly useful for discussing computer networks. ... The reverse is true of TCP/IP: the model is practicaly nonexistant."

So I'm for keeping of the full OSI model, since some teaching methods use that, and Tanenbaum's hybrid model, since some teaching methods use that. --John R. Barberio ^{talk, contribs} 12:41, 17 September 2005 (UTC)

Just because other people do things in a confusing way doesn't mean we have to. I fully approve of relegating the (semi-useless, and certainly confusing) OSI model to a secondary position. Noel (talk) 12:58, 22 September 2005 (UTC)

OSI isn't *entirely* useless - just *mostly* useless. That said, if there isn't a Comparison of TCP and OSI protocol stacks article, or something along those lines, that the material should go there; as it stands, the content is out-of-context and should be removed. --moof 18:12, 6 November 2005 (UTC)

I recently rewrote the article and put the IP stack first and then pushed all the OSI stuff into it's own section. Primarily because this article is about the IP stack, not the OSI model nor a comparison between the two — so the IP stack comes first. I think an OSI comparison is definitely warranted but after explaining what the IP stack is first. Cburnett 02:51, 6 March 2006 (UTC)

drivers comment

As the text stands it still implies that all the logic for handling say ethernet is part of the driver for the individual card. If this really is the case it needs to be stated explicitly if as i suspect it is not then it needs to be clarified that it is not. Plugwash 22:56, 6 November 2005 (UTC)

As far as Ethernet goes - yes, the drivers can and do directly affect the link layer; an example would be PHY management, or the injection of arbitrary Ethernet packets. DHCP discovery doesn't work too well if your OS isn't able to sniff packets directly at the link level. --moof 01:53, 7 November 2005 (UTC)

TCP/IP redirection change

I changed the redirection of "TCP/IP" to go to the in-depth article on "Transmission_Control_Protocol". I think that is more appropriate. There is a cross-reference to this article on the "suite" of protocols there. But I feel that if someone is specifically looking for information on TCP, then they should be driven to the specific page, rather than this more general article on all all the protocols.

I've changed the redirect back in my experiance when people talk about tcp/ip they usually reffer to the protocol suite as a whole not TCP specifically. Plugwash 04:34, 5 January 2006 (UTC)

I originally disagreed with you, but then did a little research into original sources for the term "TCP/IP". In particular, RFC 1180 (Jan 1991) states that "TCP/IP" is meant to be inclusive of everything related to TCP and IP. And so, also includes UDP, ARP, ICMP. User:mckoss 5-Jan-06

But what about Trusted Computing Platform/Intellectual Property? --Damian Yerrick (☎) 08:14, 21 January 2006 (UTC)

I wanted to make TCP/IP a link, even if it links back to the same page, because users might wonder why it is redirected here, with another name, not TCP/IP. Logictheo 09:09, 3 October 2006 (UTC)

A section regarding various names of the protocol could be added. Logictheo 08:04, 11 November 2006 (UTC)

How IP Kills and Eats Competitive Networks

Just wonderig what the value of the section How IP Kills and Eats Competitive Networks is? Written by someone with a personal gripe about the loss of a proprietary protocol?? Seems to me that common standards (such as adopting IP over a proprietary protocol) is a Good Thing (TM), but that might be my POV. In either case, the title and style of that paragraph does not look very professional, or NPOV. Comments? --CodeGeneratR 21:34, 17 February 2006 (UTC)

I agree, it is unprofessional and looks like it was written by someone with a grudge. I think the section should be deleted; it pretty much states the obvious anyway. --RobertStar20 07:32, 20 February 2006 (UTC)

I also saw this and 'wondered' is this a good or a bad thing? It does seem slightly grudge based but is also informative at the same time. I suggest that it be kept in some form, but perhaps with a better, neutral title. "How IP can spread to replace other networks" --Markavian 18:27, 1 March 2006 (UTC)

Agree to keep and reword. I don't know if it's grudge-based, but that'd have to be a looooong grudge to hold it still. Cburnett 18:58, 1 March 2006 (UTC)

Also wondering - had to prevent myself from deleting it wholesale. The title and text seem to be irrelevant, unsupported, and unnecessary. I vote for deleting it...  DavidDouthitt  (Talk) 03:09, 14 March 2006 (UTC)

Remove. It's worth mentioning that the Internet Protocols have replaced other, proprietary protocol suits, but it's not worth elaborating over more than a few senteces. --Gosub 23:32, 21 March 2006 (UTC)

DoD model

I'd have to read around some more, but is the IP suite/stack based on the DoD model? Cburnett 05:32, 6 March 2006 (UTC)

I'm wondering if its more a case of the DOD model being based on the ip stack.......... Plugwash 01:18, 19 March 2006 (UTC)

The "stack" has how many layers?

I am confused (a common state for me).

Under the heading, "Layers in the internet protocol suite stack," in the first paragraph, last sentence, it says:

"The stack consists of four layers:"

Under the heading, "OSI model comparison," second paragraph, third sentence, it says:

"The IP stack uses five layer..."

Is the significance in the words, "uses" and "consists"?

I found this to be somewhat confusing.Lord Pumpkin 01:01, 28 April 2006 (UTC)

I understand it better in this way "The IP stack 'is made up of' five layers..."? I put the words in which explain the word "consists". My learning experience declines when I read difficult words like consists. Logictheo 09:02, 4 October 2006 (UTC)

Capitalization of standard protocols - Transmission Control Protocol vs Transmission control protocol

There is a discussion and survey underway at Talk:Border_gateway_protocol#Requested_move about how standard protocols should be named in wikipedia. E.g. Transmission Control Protocol vs Transmission control protocol or Border Gateway Protocol vs Border gateway protocol . Please contribute if you can. --NealMcB 22:30, 23 May 2006 (UTC)

A comment about the article

To a reader uneducated about the array of capitalized Alpha abbreviations the article presents very much too much complexity before presenting the basic ideas. The basic idea is to uniformly transmit information in packets from a source to a remote receipient, isn't it? The theory of building a packet of reliable information is incredibly lost deep in the article after a reader wades through quantities of layers and all kinds of specialized abbreviations. The article could be presented for a common reader to understand how internet information is exchanged, instead it has elements of being a highly technical article which would not be useful to a common person. Couldn't the basics of (header information (data information) end of packet) be presented to a reader instead of involving a reader with 4, 5, 6 or 7 data layers? Terryeo 06:09, 26 June 2006 (UTC)

I think that the editors working on this article are trying to avoid redundancy with other articles on networking (notably OSI). If we have too many expository explanations of basic concepts at the beginning of all networking protocol articles, they will be too long. But I agree with you that the links to the basic concepts should be better emphasized in the first few paragraphs so that people unfamiliar with them can read about them first. --Coolcaesar 16:29, 26 June 2006 (UTC)

TCP/IP a 5 Layer Model?

Guys, great work on this article. I can see that a lot of time has been put in here. I do see where some confusion has entered the picture in regards to the layers of the TCP/IP model. I believe The RFC's define TCP/IP as a 5 layer model 1 - Hardware, 2 - Network Interface, 3 - Internet, 4 - Transport, 5 - Applicaton.

The OSI model was developed after TCP/IP was created this is why TCP/IP doesn't necessarily conform to the OSI Model. (the developement of TCP/IP staretd way back with the very begginigs of the internet itself).

My understanding the four layer model is the DOD (Department of Defense) Model. -[unsigned], June/July 2006

I concur. TCP/IP has its own funny model which does not correspond with OSI very well. OSI is used primarily as a teaching tool but then one has to study the actual pre-OSI protocol suite models on their own terms to really understand how they work. --Coolcaesar 21:38, 5 July 2006 (UTC)

Fixed layer models suck for a network as complex and varied as the internet. TCP/IP itself has two layers internet (IP) and transport (TCP,UDP and friends). There is an application above it and a link system below it each of which may have any number of layers. Plugwash 23:01, 5 July 2006 (UTC)

TCP/IP, at least RFC1122 defining its layers, is not pre-OSI. RFC 1122 was written after the OSI model was published. For the nth time, TCP/IP does not, did not, and will not follow the OSI model and efforts to force it to do so are futile. In the protocol world, OSI has been assimilated. Howard C. Berkowitz 03:04, 16 September 2007 (UTC)

OSI Model and SSL

SSL does not belong only to the session layer as it is explained in the main article. SSL is also used in the transport layer. SSL uses two protocols: one operates in a lower portion of the session layer and the other at the transport layer.

I believe that it should be explained that different references can place specific protocols at different layers.

For instance, the OSI model wikipedia article reports SSL in the presentation layer because also data encryption is involved at that layer.

SSL is the typical example of OSI multi-layer protocol.

--Rygar81 04:24, 15 July 2006 (UTC)

Layers

Isn't UDP and TCP in the same layer ? --arcade

Yes, you are right... changing it now. -- SJK

Isn't ARP and RARP in the datalink Layer? (FD)

I've know idea how this wiki things works, but I've been implementing TCP/IP since the 1980s, so I'll plead forgiveness for presenational issues in this comment. I think that the mention of layers in this article is so excessive as to be harmful. It obscures the major point: TCP/IP is the protocol of the Internet. It was designed to interconnect disparate networks, so it runs over a wide variety of media and can be implemented on a wide range of hardware. It made some interesting, and mainly correct, design choices: packetised, packet loss as a signal for flow control, heirarchical network addresses, a simple and robust directory mechanism, in-band routing and management, intelligence in the hosts rather than in the switches. The design of the protocol was a large factor in the success of the Internet, and in turn the success of the Internet is driving out all competing protocols to IP (such as IPX, AppleTalk, most SNA). There's so much more to TCP/IP than this overboiled layering discussion.

The discussion of OSI v IETF politics is naive and is best left out. An article introducing TCP/IP to the public need not get bogged down in decade-old minutia. The more significant event from that era was ARPA's funding of the TCP/IP implementation of BSD UNIX. This made a free TCP/IP implementation readily available for porting to other platforms: to the extent that most operating system's initial implementation of TCP/IP were ports of the BSD UNIX software (Windows NT, Linux, OS/370, etc).

Just to put a nail in the layering coffin, consider HTTP. The language negotiation there is OSI Presenation Layer. The ability to do multiple concurrent transfers in HTTP 1.1 is OSI Session Layer. The HTML content is obviously Application Layer. See how confusing it all gets. Such standards lawyering is fun, but it doesn't help the reader understand your point.

The discussion should mention layers only so far as they illustrate other important points. Such as the following. TCP/IP has a network layer: IP. That layer gives every machine at least one unique address (in either version 4 addresses or version 6 addresses or both). Then it has an thin adaption layer to the link layer (for example, ARP for ethernet). A major reason for TCP/IP's success is that IP was designed so this layer is thin, efficient and simple to implement. Then it has a variety of transport protocols that offer varying services: unreliable datagrams (UDP), reliable datagrams (DCCP), reliable ordered connections (TCP), reliable unordered connections (SCP), and reliable memory transfer (RDMA). Part of the reason for TCP/IP's success is that these services mapped well to what programmers needed to write applications. Such as the DNS and HTML applications you are using right now. Unlike some protocols, TCP/IP mainly implements routing, signalling and network management using TCP/IP as though they were applications; this makes routing cheap to implement and allows competition for software which supervises network elements.

Finally, to the person below that thinks OSI is well designed: it doesn't matter anymore. OSI was designed for a world of 48Kbps links and then further development stalled. TCP/IP has evolved to handle the gigabit world where bandwidth is no longer a limitation but there's a hard limit to latency, that is, on the speed of light in fiber (so TCP has evolved the TCP window scaling and TCP timestamp features). OSI had a great deal of session startup time as each layer performed feature and profile negotiation, negligble at 48Mbps but the dominant performance barrier at 10Mbps. Sure, this could be designed out of OSI, but as I noted further design work has long ceased.

What ISO wasn't was cheap: both to purchase and to run. There were no free implementations for a very long time. The telephone comanpies saw OSI working just like phones: want to do the equivalent of a DNS lookup: that's US$0.05 (in 1990) to the phone company. The phone companies all wanted regional variations too: thus the notorious GOSIP profile, where governments had to mandate a minimal set of profile contents to get some sort of interoperability. TCP/IP offered the same facilities for a lot less, on a wider variety of machines, uniformly across the world. --gdt 2006-07-31 (July 2006)

There are a lot of inaccuracies in the comments above. To the extent that they relate to the commercial failure of OSI, that doesn't matter much. To the extent they relate to creating an accurate technical description, they do. For example, misguided business practices of telco's have no connection to the efficiency of OSI. An OSI network, run by TCP/IP business practices, would look quite similar. In fact, this is not surprising, considering that quite a lot of TCP/IP comes from OSI, or shares ancestry with OSI. Paul Koning 21:46, 2 July 2007 (UTC)

Web services model? Do we need an extra layer in the future?

Where are SOAP-over-HTTP and WSDL-over-HTTP? At the application layer or above? Should it be considered as tunnelling/encapsulation, meaning that the order of the layers are changed?

Should we expect a sixth layer in the future in the TCP/IP model, above the application layer, correspodning to presentation layer in the OSI model? That layer would also include MIME, XML, HTML, JPEG, GIF, etc.

Perhaps the TCP/IP model one day will end up as a seven layer model...

Mange01 09:23, 30 October 2006 (UTC)

Perhaps, but, for better or worse, there aren't any "standard" protocols in the Internet protocol suite at that layer - the choice is somewhat ad hoc - so you're more likely to get into arguments about what layer the higher-level protocols fit into. (How, for example, would NFS's layering be described above the transport layer? XDR as the presentation layer? If so, what layer is ONC RPC at?) Guy Harris 09:35, 30 October 2006 (UTC)

Okay. But in the Template:IPstack, there should be a row for "Internet standards above the application layer". I think about MIME and others. Only protocols and other standards that has an RFC should be included there. Or do you think that MIME is not part of the TCP/IP protocol suite? Mange01 10:16, 30 October 2006 (UTC)

It's part of the suite in the sense of being defined by RFCs. Whether it's "above the application layer" is another matter; if the application layer is "whatever is above the transport layer", then it's arguably part of the application layer, but that means that the TCP/IP model doesn't have much to say about protocols above the transport layer. I suspect that, in order to say anything meaningful about protocols above the application layer, you might have to abandon the notion that there is a model with a stack of layers, and, instead, treat different applications as having different layering. With mail transport, for example, you'd have SMTP or SMTP-over-SSL, and then you'd have RFC 822 for the lowest layer of the message format, and then you'd have MIME for messages using it, and then you'd have all the different data formats used for text, images, etc.. (Of course, at that point, you either have to accept, for example, all the variants of Microsoft Word format, or you have to restrict yourself to data formats with public standards of some sort.) For NFS, you'd have the TCP record marking mechanism for NFS-over-TCP, and then ONC RPC, and then NFS - with XDR inside the ONC RPC and NFS layers (it underlies ONC RPC, in that the RPC headers are encoded using XDR, but it also underlies the protocols that run atop ONC RPC). Guy Harris 18:03, 30 October 2006 (UTC)

Right, the layering of protocols above TCP or UDP is dependent on the application and likewise the layering of protocols below IP is dependant on the network type. TCP/IPs big achivement was establishing two standard layers that could sit between a wide variety of applications and a wide variety of interconnected networks. Plugwash 17:05, 31 October 2006 (UTC)

Please emphasize the five layer model

Most text books have abandoned the old four layer TCP/IP model (and also the OSI model to some extent) in aid for the five layer TCP/IP model. It is time the pictures and text in this article are revised to reflect this. Mange01 09:09, 30 October 2006 (UTC)

Correct textbooks have not, and neither has the IETF. Are you suggesting that textbooks are more authoritative than the standards? Which is more appropriate for an encyclopedia? Howard C. Berkowitz 03:02, 16 September 2007 (UTC)

Typical implementation

Can we add something like this?

Normally the application programmes are in charge of layer 5 protocols (the appliction layer), while the layer 3 and 4 protocols are services provided by the operational system processes. Microcontroller firmware in the network adapter typically handle layer 2 issues, supported by a driver software in the operational system. Non-programmable analog and digital electronics are normally in charge of the physical layer, typically using oneapplication specific integrated circuit (ASIC) chipset for each radio interface or other physical standard. However, hardware or software implementation is not stated in the protocols or the layered reference model. High-performance routers are to a large exent based on fast non-programmable digital electronics, carrying out layer 3 switching. In modern modems and wireless equipment, the physical layer may partly be implemted usign programmable DSP processors or software radio (soft radio) programmable chipsets, allowing the chip to be reused in several alternative standards and radio interfaces instead of separate circuits for each standard, and facilitating. The Apple Geoport concept was an example of CPU software implementation of the physical layer, making it possible to emulate some modem standards.

Mange01 00:16, 9 November 2006 (UTC)

RSVP and RTP?

Searching on the Internet and in various text books, I have found that RSVP sometimes is called a network layer protocol, sometimes transport layer (seemes to be most common) and sometimes application layer. What is the truth hear? And what about the RTP protocl?

Mange01 02:13, 15 November 2006 (UTC)

The truth is quite simply that fixed layer count models like OSI do not fit all that well with the way real life networks work. Plugwash 16:10, 15 November 2006 (UTC)

Merge

I suggest merging the article Internet Protocols into this article and let that other entry forward here. -- dbu, 29 november 2006

I agree (and have added appropriate {{mergefrom}} and {{mergeto}} tags to the articles in question). Guy Harris 15:46, 29 November 2006 (UTC)

I agree. I see no reason not to do this. Reeves87gmailcom 19:34, 2 December 2006 (UTC)

I agree too. Internet protocol suite is the more widely accepted term for the whole set of protocols that are used together with TCP/IP.--Coolcaesar 23:45, 2 December 2006 (UTC)

No Nasz 10:36, 10 January 2007 (UTC)

Seems contradictory

The section called Layers in the Internet protocol suite stack seems to be in contradiction with the box: The five layer TCP/IP model.

Beside this, in the final sentence of the same section I cannot understand how in a stack with 4 layers, when one of them is splitted in two, that results in a 7 layer stack. Isn't it 6?

--201.58.179.157 05:35, 15 January 2007 (UTC)Miguel

Vandalism - ANUS

The IPstack template seems to have been vandalised with a link to 'ANUS' inserted at the start. Does anyone know how to revert that particular bit of spuriousness? —The preceding unsigned comment was added by 217.33.127.210 (talk) 10:33, 22 January 2007 (UTC).

First protocols

The article says (about TCP and IP) "which were also the first two networking protocols defined". But RFC 768 (UDP) was released one year before RFC 793 (TCP). Kasperd 08:12, 28 February 2007 (UTC)

RFC 768 says:

This User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) [1] is used as the underlying protocol.

and [1] refers to

Postel, J., "Internet Protocol," RFC 760, USC/Information Sciences Institute, January 1980.

RFC 760 was released before RFC 768. RFC 768 also refers to RFC 761:

Postel, J., "Transmission Control Protocol," RFC 761, USC/Information Sciences Institute, January 1980.

so, whilst the final RFC's defining IP and TCP came out after the final (and only) RFC defining UDP, earlier RFCs for TCP and IP came out before the RFC for UDP. Guy Harris 08:18, 28 February 2007 (UTC)

OSI to 4 layers mapping

In many modern textbooks, this model has evolved into the seven layer OSI Model, where the Network access layer is split into a Data link layer on top of a Physical layer, and the Internet layer is called Network layer.

and Application layer is split into a Application layer, a Presentation layer and a Session layer. --mj41 15:44, 6 August 2007 (UTC)

Textbooks are not authoritative references for the Internet Protocol Suite, which is developed by the Internet Engineering Task Force (IETF). The IETF has never attempted to require that its architecture be in compliance with the OSI Reference Model. The Internet Protocol Suite certainly has not evolved into the OSI model. If anything, the IETF architectural work has adopted certain features from OSI, but I doubt that you could find any serious participant in the IETF that regards the OSI Reference Model as definitive, or even desirable, for IETF work.

In point of fact, even the obsolescent OSI Model, in work under its sponsoring group, the International Organization for Standardization, is no longer simply seven layers. There is technically distressing tendency for many basic textbooks and courses to attempt to oversimplify modern protocol development by forcing protocols, not developed against the original seven layer model, into a trivialized version of the OSI architecture.

Again, in Internet Protocol Suite architecture, textbooks are not authoritative; the IETF's work, particularly the Standards Track, is definitive for the Internet Protocol Suite. I've written networking textbooks, and, while I might clarify an IETF document, I certainly don't contend that textbooks are more definitive than the actual technical specifications created by expert, not beginning student or teacher, consensus. Howard C. Berkowitz 22:22, 7 August 2007 (UTC)

Your point is well made. For clarity and brevity, I removed this material (bold below) from the introduction:

but is now viewed by some as a 5-layer model,

which gave these external links:

1. http://www.cisco.com/univercd/cc/td/doc/product/iaabu/centri4/user/scf4ap1.htm
2. http://www.cacs.louisiana.edu/~mgr/404/burks/pcinfo/hardware/ethernet/tcpip.htm
3. http://www.et.put.poznan.pl/tcpip/architecture/archi_layers.htm

The second link is dead, and the other two show a four layer stack. The confusion (or evolution) of 4 vs. 5 layers doesn't seem a significant enough point to be in the introduction at all. Perhaps a mention in the section detail is appropriate. Continuing:

as a 5-layer model, even though no IETF standards-track document has accepted a five-layer model, and IETF documents indeed deprecate strict layering of all sorts. Given the lack of acceptance of the five-layer model by the body with technical responsibility for the protocol suite, it is not unreasonable to regard five-layer presentations as teaching aids, possibly to make the IP suite architecture more familiar to those students who were first exposed to layering using the OSI model. Comparisons between the IP and OSI suites can give some insight into the abstraction of layering, but trying to coerce Internet protocols, not designed with OSI in mind, can only lead to confusion.

If supporting cites can be found, this can be reduced to

Confusion exists in some circles over whether TCP/IP follows or rejects the OSI model. It does neither, instead defining its own four-layer model.

Or something like that. But it looks like some reconciliation with the infobox is needed. —EncMstr 17:56, 15 September 2007 (UTC)

There is no section in this article about the "session layer" because there is really no such thing in the internet protocol suite, its only brief mention is as part of how people shoehorn TCP/IP into the OSI model. With the TCP/IP everything above TCP or UDP is the responsibility of the application. Plugwash 16:57, 31 October 2006 (UTC)

http://www.ietf.org/rfc/rfc1122.txt defines 4 layers. If anyone can find another IETF document that states the OSI model is followed, please cite it. Further, RFC 1122 was published in 1989, while the OSI Reference Model, ISO 7498, was published in 1984. If the RFC 1122 authors had wanted to be OSI compliant, they had the OSI definitions available to them. They didn't use them. Howard C. Berkowitz 19:07, 15 September 2007 (UTC)

I've expanded on this somewhat on my user talk page. Howard C. Berkowitz 03:00, 16 September 2007 (UTC)

Footnote number 3 is a very funny joke and I cannot remove it

Somebody vandalised the page is portugese, but he was trying to illustrate the point which somebody else is illustrating. Who checks the links of the footnotes? nobody. who ever checks any footnotes? nobody? Anyway I cannot find a way to remove this footnote. Possibly the original practical joker found a way to embed it in a way which is not removable. 2 good arguments against footnotes in principle and into practise? Wiki104 20:43, 30 October 2007 (UTC) Correct footnote should be http://news.bbc.co.uk/1/hi/technology/4415326.stm —Preceding unsigned comment added by Wiki104 (talk • contribs) 20:50, 30 October 2007 (UTC)

Which one? Reference 3 in the article looks good to me - it mentions an "informal report".

Also, the section you inserted is much too big and textbook-like. Can you condense it to something much smaller, with headings and sub-headings? The wall-of-text look isn't what Wikipedia encourages. Acroterion _(talk) 20:56, 30 October 2007 (UTC)

Okay acterion. Do you actually read what you are looking at? Here it is.

And finally, the first return pigeon arrived. The packet was carefully removed from the leg, unrolled and scanned. After manually verifying the OCR and correcting the few mistakes (gocr is quite good, but it *did* have problems recognizing F's in my end), the packet was accepted as a valid packet, and there was much cheering about what we saw:

64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms

The remaining pigeons arrived simultaneously. Two of them didn't have any IP packets, though, it turned out that things had been so busy at the other end that they forgot to shut the pigeon cage, and the remaining two pigeons escaped without an IP packet. There was only six return pigeons, thus we got four ping replys, with ping times varying from 3211 to 6389 seconds. I guess this is a new record for ping times...

The implementation was declared a success. Now, we're waiting for someone to write other implementations, so that we can do interoperability tests, and maybe we finally can get the RFC into the standards track...

!!!!! So messenger pigeons are going to become an internet standard like Domain name resolution?

Now HERE THIS. A wall of text is preferable than factual mistakes if the wall of text is factually correct and based upon knowledge and not bunkum presentation skills whereby there is no substance. On subnet masks page you happened to change the IP address of class C network from 192-233 into 192-254 on subnets page. the 254 possible hosts are by the 4th octet only. I haven't time to be correcting these mistakes and running around after you. I have no desire to monitor any wiki page at all. If you don't understand the subject matter please stick to what you do know about. I have never attempted to write a wiki page about architecture because I wouldn't be able to do so. The wall of text is fine. The whole of the developing world like it and need it, and I am sure that the founder of wiki would like it also. There is not a problem with proper knowledge being concisely inserted. Try assessing the substance as knowledge rather than worrying about progress. Desires by immutability are worry and all paranoia dislikes a full narrative, and so wishes to break every. sentence. down. shorty. shorter. abstract. drivel. heading. sub-heading. section. .nice to . look. at. exclusively without perspicuity. Do I sound like an Indian guru? Wiki104 11:29, 31 October 2007 (UTC)

I saw no Portuguese, and yes, I read the "joke", which was inappropriate. So remove the reference. As far as editing goes, you will need to follow Wikipedia guidelines when you do so. I claim no particular expertise at IP addressing, but I can copyedit. Feel free to correct my factual mistakes (nicely, please), but please understand that inserting blocks of informally-phrased text is not productive, regardless of your good intentions. Acroterion _(talk) 12:07, 31 October 2007 (UTC)

What part of "I cannot remove it" do you not understand? On the subnet page I included a lot of stuff which was factually incorrect as a tester. Nobody noticed. You copy-edited and left in all the stuff which was wrong which I had put in. I have now corrected it properly. I am afraid that we can read guidelines until the cows go home but this will not help us convey any knowledge. I do not wish to have any further discussions with you about a "wall of text". The subnet mask page was almost empty before I appeared. I have contributed most of its current content. The majority is definable as a wall? I thought that walls were built of bricks or wood. I am not being pedantic but this is going to get personal because I am certain that you are not able to edit the pages which I have shown an interest in. I have a degree in this subject. Now could we please leave this here, and please stop following me around with these criticisms. You might be trying your best, but sometimes rules without interpretation, presentation without substance, and being a pedant without comprehensive knowledge is counter-productive by the common good and the developing world at India. There is a old expression : there is not progress without pain. So please stop stalking me because i have much more to do here before I am finished. I have done another by DNS pages, but I could live without all this childish behaviour so I am reluctant to make additions further. Do you do this full-time? Wiki104 13:02, 31 October 2007 (UTC)

I think you've missed the point of that reference; its inclusion is debatable, but I read it as germane to the illustration of the simplicity of the IP concept. I suggested that you remove it because it would give you some experience in referencing in Wikiformat. Since you seem to believe that there is a problem with my participation in this discussion, I have initiated a request for comment that will bring other eyes and opinions to bear on the article. Acroterion _(talk) 13:23, 31 October 2007 (UTC)

Good grief. I have not been able to remove. I have tried. What I think has happened is that the wiki source code is probably open. Some clever people have found a way to invoke some mark-up language in a special way. This has created the content of the link not visible to us with our pitiable http interface. The reference is not visible on http!!! Please request for comment yes. If anything it will create discussion about this security flaw in wiki pages.

As for the suggestion that the link was a sincere one. I can believe that you are still saying this because you have said it. Earlier on page [3] was supposed to be a footnote about a medal for american culture. that was the link I did a google search on and found the correct link (above). In britain we call a practical joke like this a P***-take. It was hilarious. I laughed a lot. It illustrates that the emperor could have no clothes on, and in a cruel way the stupidity of some people. IP packets are not simple and in no way represent a pigeon or a ping or milliseconds or the hexadecimal as F which the manual optical character recognition (eyes) had difficulties deducing. Anyway I have plenty more content to add to wiki. The wall of text was probably a rule created to avoid a cut and paste job. It really needs amending! It should not be interpreted as "narrative is prohibited". All coherent and loqacious lucidity is a flow of text into a certain mode.Wiki104 14:50, 31 October 2007 (UTC)

All you have to do to remove an embedded reference is to remove it where it occurs in the text, not down in the notes section. In this case, you'd remove <ref>[http://www.blug.linux.no/rfc1149/writeup.html The informal report from the RFC 1149 event.]Bergen Linux User Group,April 2001</ref> from the offending anecdote (although if you do that, the whole sentence should go). And I remind you again - no matter how good your intentions may be, every editor is obligated to follow Wikipedia guidelines for style, organization and referencing. I strongly urge you to use references, as unreferenced material, whether it's pigeons or bits, has a short life. The commonly used phrase here is "verifiability, not truth", as truth is hard to independently reference. And as much as I admire the phrase "coherent and loqacious lucidity", encyclopedias tend toward concision, not loquacity. Acroterion _(talk) 15:13, 31 October 2007 (UTC)

Okay well concise mean perspicacious perspecuity, which means that you know how to get across the complete picture, and have the whole picture in your head. loqacious means really talkative, so perhaps too much talk is going too far, but I see people talking to themselves everywhere. Emmimem put it succinctly "these days seems that everybody wants to talk, seems that they got something to say, but nothing comes out when they move their lips: just a bunch of jibberish."

concise does not mean short: that is a conceptual error. Concise mean that you do not waste words. Conveyance is impossible by too few words and made unreadable by too many. I have not seen much conveyance re internet wiki pages. Grammar is a big problem. I struggled over many years to use the American-British grammar. I finally abandonned it completely in favour by communication with 90 per cent of the global population. I am certain that we do not need to tell Americans about IP address. We do need to tell the developing world about IP addresses. Wiki104 19:59, 31 October 2007 (UTC)

Bizarre. Are you seriously claiming that you can't communicate in English to 90 percent of the world in standard English, but that you need some home-made grammar of your own to do it? That's pretty insulting as well as implausible. In any case, it isn't going to impress anyone else, so if that's how you write your contributions they are going to end up either scrapped or completely redone by other editors. Paul Koning 11:00, 1 November 2007 (UTC)

It's hard to tell anymore what this section is all about. The original issue seems to be the [3] in the text about Kahn and Cerf, which looks like a footnote reference but isn't. I removed it. Paul Koning 18:32, 31 October 2007 (UTC)

RfC

Large quantities of text have been added to this article, and should be reviewed for accuracy and general applicability. The article also appears to require significant copyediting for style and tone, and formatting by someone familiar with the topic. Acroterion _(talk) 12:31, 31 October 2007 (UTC)

This user has passed comments about everything which I have ADDED since I arrived here. I have added a lot of useful things such as explanations and narrative which are useful and anti-brainwashing. It is very easy to become lost. We all try our best but sometimes we are wrong about things and have no knowledge about why we are wrong. Although things might seem worrying to ourself it is not always the case that worries are a rational perspective about the outside world. There is a chinese proverb which states there never was an individual who did harm who did not believe that he was doing the right thing. Wiki is supposed to transfer knowledge from the developed world to the developing (introduction). I have done so for 10 days now. See TCP/IP discussion for more details. Also acroterion home-page. NEED SUPPORTIVE COMMENTS TO ALLAY THE FReNeTICWiki104 15:06, 31 October 2007 (UTC)

Please keep in mind that this is about content (including style), not about who writes what.

The new text has lots of grammar problems, and the style likewise needs adjusting. The other question is how much detail belongs in this article. Right now it basically has a graphic that shows the layers, and that references articles about each layer. So a detailed description of each layer would be out of place. But a brief description of what each layer does, to expand on that one-word mention in the graphic, seems like a good idea. Paul Koning 18:37, 31 October 2007 (UTC)

Hi, I came here from the RfCsci page. I've reviewed the new additions (mostly the "Explanation to TCP-IP"[sic] section, and besides being badly worded and written in an informal, unencyclopedic tone, it largely duplicates the existing article. The only real information in here (that "TCP/IP" is a suite of more than two protocols, the history with DARPA, and the network layer interaction) is already covered in the existing sections, and with far better grammar. Also, it goes into some pretty specific details about MAC address lookups and using the ARP utility, neither of which belong here. The MAC address stuff has it's own page, and wikipedia is not a manual. I'd say the whole "Explanation to TCP-IP" section can go. — EagleOne\^Talk 18:45, 9 November 2007 (UTC)

Hi, I also came here fro the RfCsci page. I went through the section and removed the paragraphs that were either: 1) already covered elsewhere in the article (how the protocol stack works, encapsulation), 2) incorrect or confusing (need to be very clear which protocol layer is explained, also no need to explain how disk IO or CPU scheduling works), 3) paragraphs that are already handled in other articles (protocol specific explanatinos). Unfortunantely in the end nothing remained of the section. But I would encourage the original author to continue contributing. However, the best place to start is probably not explanations of high-level well-known concepts in Computer Science as these tend to be covered already.Labongo 18:18, 13 November 2007 (UTC)

Edits have now been reviewed so I have removed to RfC tag.Labongo 13:08, 16 November 2007 (UTC)

Cat Herding Nearly Complete

I believe I have gotten most of the RFC references into the desired cite web format, although there is something quirky about RFC 1149, for which I can't get the URL to stop showing up in the references.

May I make several clarifications, from quite a bit of direct experience in the development of OSI and IETF protocols and architecture? First, it never was the intention of the IETF to be compliant with the OSI Reference Model. As far as there being a number of layers, it is not seven, not three, but four. Four is the number of the layers, as specified in RFC 1122. Don't argue with me, argue with the Killer Rabbit, and try holding the Holy Hand Grenade of Antioch for a count of 5 or 7.

The IETF, however, has long recognized that strict layering was once useful conceptually, has limited use in teaching to beginners, but no IETF working group in which I've ever participated ever spent more than a few seconds on layer numbers -- other than to say we don't do layer numbers. When getting into recursive layering with such things as stacked MPLS labels, IP in IP, or real-world implementations of things like TCP in IP in PPP in UDP in IP in 802.2/802.3 frames over ATM LAN emulation, layer numbers simply don't work.

For those unconvinced that seven layers aren't struggling to get out, not even ISO insists there are seven layers. Yes, the original OSI Reference Model in ISO document 7498 had seven layers, but the Internal Organization of the Network Layer, in ISO 8648, split the network layer into three sublayers. The lowest of those sublayers blurs when dealing with pre-OSI protocols such the X.25 packet layer protocol, and also with the IEEE Project 802 split of the Data Link Layer into LLC and MAC. LLC, with the SNAP extension, is also used in "layer 2" protocols such as Frame Relay.

No authoritative source anywhere suggests this model has five layers. That appears in a few textbooks, and is flatly wrong. No major vendor describes it as having five layers; I was first a Cisco Certified Instructor in 1991, contributed to many Cisco courses, and was a router designer for Nortel from 1999-2001. I have never seen anyone suggest five layers other than Wikipedia and a few textbooks. If you want to fail a certification exam from any vendor, say this model has five layers.

Can we all just get along now (and could someone figure out what's wrong with the RFC 1149 cite so that it keeps embedding the URL in the footnote)? Howard C. Berkowitz (talk) 21:42, 20 November 2007 (UTC)

Reverted External Link Is Valuable to Have

I think the link we had pointing to http://www.learn-networking.com/tcp-ip/introduction-to-tcp-ip-protocol-suite.php was very valuable to have. It was taken out by a microsoft address, with no reason provided. Who thinks it should be reincluded? It has a good explanation of TCP from the very beginning- great for newbs. Zac439 (talk) 20:41, 20 November 2007 (UTC)

It's been a couple of days. If no one has any objection, I'm going to re-include the link. Zac439 (talk) 11:41, 22 November 2007 (UTC)

I don't see anything wrong with it. I just added it back to the article. — EagleOne\^Talk 22:09, 22 November 2007 (UTC)

Thanks for the feedback EagleOne, and happy thanksgiving! - Zac439 (talk) 18:23, 22 November 2007 (UTC)