Talk:Transmission Control Protocol

TCP is not a virtual circuit protocol

TCP is not a virtual circuit because the connection state resides only on the two send systems. Any intermediate nodes are not aware of any of the TCP parameters. Fisherisland14 19:27, 25 September 2006 (UTC)[reply]

TCP is a virtual circuit protocol because the connection state resides. Intermediate nodes need not be aware of any parameters for a protocol to establish a virtual circuit. Here are two external definitions:

[1]: A connection between communicating computers that provides the computers with what appears to be a direct link but can actually involve routing data over a defined, but longer path. - no mentions of necessity of intermediate nodes being aware of anything.
[2]: A defined connection between two end-points in a packetized network. While the two ends of the virtual circuit are defined, the path used by the network to connect the two end-points is not necessarily predetermined. - explicitly said that intermediate nodes not important. Nikola 15:07, 13 October 2006 (UTC)[reply]

TCP state diagram be useful?

After pondering this for a while, I'd say "no", because I think it would be too detailed for Wikipedia. We're not supposed to be an expert-level reference work - that's what "Further reading" and "External links" are for. I mean, do we really want to get into "Fin-Wait-1" and such things here? I think not... Noel 13:01, 4 Oct 2004 (UTC)

I think the answer is YES! A diagram would be the most concise and useful expression which shows how TCP really works. By your arguement, the whole listing of the states in TCP in words should be deleted. I feel that Wikipedia readers that come to the very detailed page, should get a proper diagram of the TCP state machine. Note also that the graphic in RFC 793 is text-based and very hard to read. Wikipedians deserve a really nicely drawn one. Mike 4 Jan 2005

I agree that the state diagram is useful. However it only includes the set up and tear down phases of TCP - it doesn't expand on the "data transfer" state, which should have data ACK and ACK states showing the data flow. 22 Nov 2006

Checksum

The TCP checksum -- isn't it more properly referred to as the one's complement of the one's complement sum? In any case, I'm removing the link to one's complement in the article, because that gives a *very* misleading impression of how to calculate the checksum.--Ryan Stone 19:01, 8 Nov 2004 (UTC)

RFC 793 calls it the one's complement of the one's complement sum, so that's what I'm putting in the article.--Ryan Stone 19:08, 8 Nov 2004 (UTC)

Yes, it's the complement of the sum, so that when you receive a packet, you don't have to zero out the checksum field (after first storing the checksum), and then compare the checksums afterwards - you just sum up the packet, with the received checksum in situ, and the resulting sum should be 0 (actually all 1's, which is also zero in one-comp notation - there's no way to add up any sequences of non-zero numbers and get 0 as the result in one's-comp addition, due to the wrap-around add of the carry). I'll add this to the article, along with why we used a ones-comp sum to begin with. Noel (talk) 14:22, 14 Nov 2004 (UTC)

Is it really appropriate to have the ellipsis after the Network Layer enumeration of IPv4, IPv6, and ARP? Are there really other network layer protocols?

TCP windows or Windows' TCP

In the paragraph titled TCP window size: "The Windows TCP/IP stack is designed to self-tune itself" - do you mean Microsoft Windows ? (Since "window" generally means something else in this paragraph). If yes, make it explicit. If no, why the word order and capitalization?

This confused me too, so I googled the phrase. It looks like that paragraph was ripped off of [Microsoft] (I really doubt the other way 'round....). Anyway, in the context of the microsoft article, it clearly refers to Microsoft Windows 200x.

Ah, both the Window scaling and the Window size sections are ripped off of that MS article. Probably more.

Jeff 02:11, July 12, 2005 (UTC)

Software limitations -- totally unreliable claims

From the article:

Networking speed gradually increased over the years. What started as a protocol built for unreliable low speed networks (few Kbytes per second) is now required to run at 1 Gigabit per second. The TCP software implementations on host systems require extensive computing power. Gigabit TCP communication, alone, eats up 100% of a 2.4 GHz Pentium 4 processor.

The latter point is totally uncited, and omits several facts that are essential to judge the statement. For instance, TCP implementations vary widely, as to OS responses to high load, particularly I/O load. What operating system was this metered on? What kind of load was used? I would expect, for instance, that a 2.4GHz Pentium 4 being used as an Ethernet bridge in Linux, using zero-copy forwarding, would have very different performance characteristics from one being used as an FTP server in Windows.

These claims need to be cited with details, or else they should be deleted. --FOo 02:34, 27 Jun 2005 (UTC)

Agreed. My 2.0 GHz 2400+ XP Athlon w/ 512 MB ram running 2.6 gentoo linux sees hardly any CPU time for my gigabit card. Cburnett 04:15, Jun 27, 2005 (UTC)

Removed since I think it's sufficiently wrong to merit proof for inclusion. Cburnett June 28, 2005 07:58 (UTC)

NPOV?

Forgive me if I'm incorrect, I'm a newb at wikipedia. Doesn't this bit go against the whole "neutral point of view" philosophy?

"A better solution..."

It almost sounds like whoever put that bit in was just trying to advertise "NTA"

That paragraph seemed to be simply an advertisement. That's not just an "NPOV" violation, it's spam. (To the person who added it -- please learn how not to be a spammer.) Deleted. --FOo 14:32, 1 August 2005 (UTC)[reply]

Paragraph "Data Transfer" is duplicated

The paragraph "Data Transfer" appears twice in the article, once in its own paragraph and once under Connection Termination further down,

State diagram

The german article is a featured article so when I checked it out I noticed that it had a state diagram: de:Bild:Tcp verbindung.png. If anyone feels like doing a little editting to change the german to english...that'd be spiffy. Cburnett 06:16, 22 February 2006 (UTC)[reply]

Done. Raul654 07:03, 22 February 2006 (UTC)[reply]

"Active Open" / "Passive Open" in connection terminating state box, should be "Active Close" / "Passive Close" respectively?

Termination: a three- or four-way handshakes

There was a point of contention regarding the number for describing the handshake process in the connection termination. Someone recently reverted an edit to say it is four, not three.

The teardown seems to be very similar to the setup: Each side sends a FIN and responds with an ACK, making the process:

1. Side A sends a FIN packet 2. Side B responds with an ACK/FIN 3. Side A responds with an ACK

This seems the most likely way most teardowns operate. A half-open connection where B acknowledges without sending the FIN could cause it to be four-way, of course, but this seems rather rare. Perhaps it could be:

"three- or four-way depending on the first response."

--Kevin L'Huillier 02:41, 10 March 2006 (UTC)[reply]

It's a 3 way handshake. Every scintilla of literature on the subject refers to it as a 3-way handshake. Raul654 02:48, 10 March 2006 (UTC)[reply]

Okay. I will revert the revert, but also add that it could take four steps if it is intentionally left half-open. --Kevin L'Huillier 04:47, 10 March 2006 (UTC)[reply]

Yes, it's commonly a 3-way handshake by combining the FIN & ACK together. However, the process is really a 4-way (FIN1, ACK1, FIN2, ACK2) and the 3-way is merely an "optimization".

To me, a "way" in handshake is an agreement of the state of a channel. Prior to closing either end the channel is open. The first FIN indicates the sender has closed its end. The corresponding ACK acknowledges the state (2 ways). At this point the state is agreed to be half-open. The non-initiator can optionally bundle its FIN with the ACK if it has nothing to send (why would you send 2 packets when you can send one???). Finally the initiator ACKs the non-initiators close. So, in all, it is a 4-way handshake — there are four steps to completely close a connection.

On a related tangent, an ACK is a 2-way handshake. The sender's data is acknowledged thus "stating" that the data has been received. The ACK is usually bundled with other data because there's no reason to transmit a separate packet for a flag and a few bytes. The 3-way handshake is the exact same scenario: just bundling an ACK on some sender's data (a FIN).

Raul, every scintilla? You might try the TCP/IP Protocol Suite by Forouzan (ISBN 0-07-246060-1) on page 328 (2nd ed). It describes it as a four-way handshake.

Regardless, I believe my version is down the correct road. Explain it all sufficiently so the reader understands it and can take it as they please. Saying it's a 4-way because that's what it is, and adding that there are common optimizations is the best approach. Cburnett 01:12, 11 March 2006 (UTC)[reply]

Additionally, Raul, look at the very RFC that defines TCP: RFC 793. Page 23 shows the state diagram for TCP. There are two paths:

3 transitions and 4 states: ESTABLISHED -> FINWAIT-1 -> FINWAIT-2 -> TIME WAIT
3 transitions and 4 states: ESTABLISHED -> FINWAIT-1 -> CLOSING -> TIME WAIT

The first path is the non-initiator closing after the initiator closes. The second path is the case when both ends close simultaneously (both receive the FIN before receiving their ACK). So it's clearly a 4-way: the reception of an ACK is distinct from receiving the FIN. Cburnett 01:28, 11 March 2006 (UTC)[reply]

Even-more-additionally: The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference by Charles Kozierok (ISBN 159327047X) describes it as a pair of two-way handshakes. Cburnett 04:37, 12 March 2006 (UTC)[reply]

Everyone has made good points.

A related question is: Why is the establishment considered three-way? It is conducted in a very similar manner ie. it could be SYN, ACK, SYN, ACK instead of the usual SYN, SYN/ACK, ACK. Should it be considered a pair of two-way handshakes, and therefore four-way as well?

--Kevin L'Huillier 03:01, 28 March 2006 (UTC)[reply]

I guess I'd have to wager it's not a 4-way because whether or not the SYN/ACK is split up the connection cannot continue. If A SYNs and B ACKs then A cannot send data because it hasn't ACK'ed B's SYN. Regardless, one or two packets for the SYN/ACK doesn't change the connection state: A cannot send until it's ACK'ed B's SYN.

This contrasts highly with termination where B can still send data to A until B sends a FIN to A. There is clearly a state change (A can no longer send data) that doesn't exist in connection establishment.

I have also never seen the connection be referred to a 4-way. Not wanting to fall into the argumentative trap Raul fell in, I'll point out tha if connection were considered a 4-way then I'd beleve that would come from the same sources that say termination is a 4-way handshake but they don't. They all say 3-way.

So it's not the number of packets or flags sent, but the number of state changes that matter. Cburnett 04:16, 28 March 2006 (UTC)[reply]

Ah, that makes perfect sense. Thank you. --Kevin L'Huillier 18:14, 29 March 2006 (UTC)[reply]

Poor definition methodology

Just making a simple observation: Several examples in this article casually use the accronym TCP in its own definition, which is generally considered poor practice. E.g. ...Any SYN packet holds Sequence Number. The Sequence Number is a 32-bit field TCP segment header...

In this case it could be considered confusing to the laymen to use the subject of the article in its own definition.

Comment: But does it really matter? Laymen wouldn't understand the details of the protocol anyway...and are probably not interested in try to understand them. — Preceding unsigned comment added by 74.93.1.129 (talk • contribs)

iTCP

I'm in two minds about whether this should be here as this is more about research than TCP. What are others thoughts? In the meantime I'm fixing the grammar and links up a little... --Imcdnzl 00:21, 16 May 2006 (UTC)[reply]

I've asked Oldiowl to tone this down a bit as it sounds like an advertisment for iTCP at the moment. --Imcdnzl 03:45, 16 May 2006 (UTC)[reply]

Thanks for your comments. I have toned it down. See if it reads better?

Just a note.. iTCP also has FreeBSD impelementation. It is just new. Note many others linked/explained/pointed variants of TCP are also predominantly research system. Fast TCP, TCP Hybla, H-TCP, are in this class. Many even have no record of implementation. However, it is possibly Ok to list such research grade systems for discussions of current transport protocols.

I tried to follow TCP Hybla pointer but it does not seem to point to a page with obvious connection to a TCP protocol description. Does anyone know about this link?

thanks, Oldiowl

OK. I'm editing this after reading about iTCP some more. It is actually quite interesting and relevant to my research but the edits on this page are inaccurate and do not need the prominence that they have been given.--Imcdnzl 21:10, 18 May 2006 (UTC)[reply]

Datagram

What is a datagram, and does TCP count as a Datagram? Mathiastck 21:25, 13 July 2006 (UTC)[reply]

What I have been told at university is that "Datagram" is the name of the PDU for UDP, while "Segment" is the name of the PDU for TCP. El pak

Few responses to above

As someone who originally did much of this article, I'd like to challenge the whole notion of 3-way and 2-way termination handshake. I don't believe that is really any such thing, I think what this is, is some stacks "cheating", but I'll dig into it to verify. And the 2-way handshake, that certainly sounds made up. Going by the state diagram and calling it 2-way or 3-way based on that is a bit misleading I think. In any case, I don't believe anyone ever refers to the connection termination as a handshake and pretty sure never a 3-way or 2-way handshake, but I'm prepared to be proven wrong. ...and we refer IP datagrams, UDP messages and TCP segments, but most people tend to say "packets" and that is generally fine unless one is being particularly pedantic. It looks the article needs some other minor updates since I last looked and I'll try to do my share soon.

History

There's no mention of who developed TCP, or how it came to be. — Preceding unsigned comment added by 62.79.44.136 (talk • contribs)

Thank you for your suggestion! When you feel an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the Edit this page link at the top. You don't even need to log in (although there are many reasons why you might want to). The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes — they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. --FOo 07:51, 15 August 2006 (UTC)[reply]

There is a good history at Internet protocol suite which contains TCP within it, so if you wanted more, also consider putting it there instead. — RevRagnarok ^{Talk Contrib} 10:45, 15 August 2006 (UTC)[reply]

"TCP Reno"

To the best of my knowledge, "TCP Reno" is a name invented by Larry Peterson, and not used by many other researchers. At the time Van Jacobson was developing the original congestion mitigation algorithms, it was expected that they would be released in 4.4BSD. Development of 4.4 took much longer than anticipated, and an interim release, 4.3BSD-Reno (successor to 4.3BSD-Tahoe), was made to get the code out into the hands of ISVs. It was published in the "Networking 1" release about the same time. 18.26.0.5 22:25, 11 September 2006 (UTC)[reply]

Application/transport dependency misnomer

From the article:

"Common applications that use TCP include HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (e-mail) and FTP (file transfer)."

The phrasing in the article tacitly implies that as part of their specification application layer protcols must use TCP. This is not entirely accurate. From RFC 2616:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.

—Super j dynamite 04:56, 19 September 2006 (UTC)[reply]

That may be true in a pedantic sense but the reality is that http is used either directly with TCP or with SSL over TCP. Are there even any standard url schemes that can specify a http connection over something other than TCP or SSL over TCP? Plugwash 11:01, 22 October 2006 (UTC)[reply]

over time diagram?

What do you think of adding that kind of diagram to the article? I personally find them simpler to understand than the state diagram. I'll try to do a draft tonight (EST). -- lucasbfr ^talk 14:15, 11 October 2006 (UTC)[reply]

what do you think? -- lucasbfr ^talk 00:38, 17 October 2006 (UTC)[reply]

The visual quality doesn't match what is already present in the article. Additionally, it is confusing where the actual data communication occurs - you seem to be showing a very limited one-shot request, like HTTP or something. I think I'd prefer to break it into two images with "setting up" and "taking down" separated. — RevRagnarok ^{Talk Contrib} 10:55, 17 October 2006 (UTC)[reply]

Thanks for your input. As I said, that's a draft more than anything else. I'll see if I come with something else. -- lucasbfr ^talk 13:27, 17 October 2006 (UTC)[reply]

I was actually looking for a diagram like this in the main article! May be a trace screenshot from WireShark would suffice. 21 November 2006

SYN Merge

Not enough info on SYN for a good article, and ACK already redirects here. --Ortzinator 15:18, 27 October 2006 (UTC)[reply]

Sounds like a good idea to me: One specific packet type of a protocol is probably a little over-specific. DStaal 18:27, 27 October 2006 (UTC)[reply]

Merge, such as it was, done. Guy Harris 00:25, 22 November 2006 (UTC)[reply]

Remarks

Someone should change sentences like "TCP is optimized for ...". TCP is developed for wired networks, but not optimized for such scenarios. Mathematicians can optimize something, engineers improve something! And have a look outside the USA. Good ideas how to improve TCP are not restricted to USA researchers. Therefore, I have added a link to my two-year old (!) dissertation.