Talk:Transmission Control Protocol

message: When you read this section "Furthermore, TCP senders can use path MTU discovery to infer the minimum MTU along the network path between the sender and receiver, and use this to dynamically adjust the MSS to avoid IP fragmentation within the network.", you can say it implies that:
1. MSS can be derived from the Path MTU 2. MSS can be adjusted after it is sent to the other end.
MSS can be calculated based on the MTU of the locally attached network, and not the minimum MTU along the path (PMTU). MSS can not be adjusted after it is sent (only) in the [SYN] packets during the three-way handshake. So better to change the lines or the wordings.  — Preceding unsigned comment added by WikiJackool (talk • contribs) 05:01, 16 January 2016 (UTC)
thread_title: Maximum Segment Size

message: Regarding
: Port numbers are categorized into three basic categories: well-known, registered, and dynamic/private.
It seems like it might make sense to link to Portmap and possibly even the "little used" TCP Port Service Multiplexer pages as examples of dynamic port usage (with liaison on a well-known port). JimD (talk) 00:56, 20 June 2015 (UTC)
thread_title: TCP ports

message: I think the phrase "purposely assembled SYN packets" should be replaced with  "degenerate SYN packets" in this section as this would more accurately convey that the such packets are malicious and not conformant to the relevant standard semantics.  — Preceding unsigned comment added by JimD (talk • contribs) 00:48, 20 June 2015 (UTC)
thread_title: Denial of service

message: 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)
replies: text: 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)
thread_title: Checksum

message: 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)
thread_title:  NPOV? 

message: The paragraph "Data Transfer" appears twice in the article, once in its own paragraph and once under Connection Termination further down,
:I have checked this item and I propose mark it as .--Jimmy Olano (talk) 18:49, 4 August 2019 (UTC)
thread_title:  Paragraph "Data Transfer" is duplicated 

message: The german article is a featured article so when I checked it out I noticed that it had a state diagram: .  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)
replies: text: Done. Raul654 07:03, 22 February 2006 (UTC)
thread_title:  State diagram 

message: 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)
replies: text: 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)
thread_title:  iTCP 

message: What is a datagram, and does TCP count as a Datagram? Mathiastck 21:25, 13 July 2006 (UTC)
replies: text: It would improve this article greatly to respond to questions with adding simple explanations to the article, and not left as an excercise for the reader.  —Preceding unsigned comment added by 67.174.157.126 (talk) 22:22, 5 May 2008 (UTC)
thread_title:  Datagram 

message: 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  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)
replies: text: 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)
thread_title:  History 

message: 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)
thread_title:  "TCP Reno" 

message: 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)
replies: text: 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)
thread_title:  Application/transport dependency misnomer 

message: Not enough info on SYN for a good article, and ACK already redirects here. --Ortzinator 15:18, 27 October 2006 (UTC)
replies: text: 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)
replies: text:  Merge, such as it was, done. Guy Harris 00:25, 22 November 2006 (UTC)
thread_title:  SYN Merge 

message: 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. —The preceding unsigned comment was added by 217.247.67.233 (talk) 03:03, 9 December 2006 (UTC)
replies: text: To the best of my knowledge, the problems with TCP over wireless haven't been solved, they've merely been ameliorated somewhat.  The problem is that TCP assumes that dropped packets mean congestion, because that's almost always the case in current highly reliable wireline networks. Obviously, wireless networks drop packets for many reasons.  Ngriffeth 14:07, 3 July 2007 (UTC)
thread_title:  Remarks 

message: Anybody got the RFC that explicitly backs up the segment structure displayed? I know its implied in the RFC's but I cannot find an RFC that backs this version up, and it is distictly different from http://tools.ietf.org/html/rfc793#page-15
--Whisper555 07:31, 3 July 2007 (UTC)
replies: text: Come now. The TCP headers don't change that much, that often. :) The point I was making is that the current diagram & subsequent explanations do not match RFC 793. I personally know why they don't, but that doesn't mean everybody else will, and it is confusing if you do look at half the resources on the Internet & in books which match the RFC 793 and the other half do not, and in Wikipedias case, without explanation or citation. I am not going to commit suicide if it is not changed, but this is my simple suggestion to hopefully create a better, more authoritative article. --Whisper555 03:29, 4 July 2007 (UTC)
replies: text:  Sorry, I was just threatening to be aggressive (isn't that recommended by the Wikipedia guidelines? :-)) I compared the wikipedia diagram with the RFC793 diagram in section 3, page 14.   I see two differences that are completely inconsequential as far as correctness and a third that is indeed interesting but only to people who really care: (1) the spacing on the wikipedia diagram gives the visual impression that the first 16 bits of each word are longer than the last 16 bits, which is obviously not true and I assume not intended, and redrawing the diagram to fix that would definitely be good and (2) the padding field that's included in the RFC is missing here (the padding field documents the fact that if the options don't end on a word boundary, then padding is inserted - seems likely to be confusing to  lay reader since padding is likely not to be there in any given packet).  The other difference is that two flag bits have been added to the flags field, using a couple of the reserved bits.  Let me congratulate you, picking up these two bits takes incredibly careful reading!!  Because it incorporates these bits, the wikipedia diagram is more up-to-date than 793 (as is to be expected, since 793 is really old and has been updated by several subsequent rfc's).  Take a look at RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP.  Omigod that's mean - the title really doesn't give you a clue about the change to TCP.   You should be able to find this kind of change by following the "updated by" links in the index to RFC's.   But then again, if you do this and look at the title.... you probably just keep looking.  As to textbooks, some are more up-to-date than others; also, I don't think 3168 is a standard yet, it's just an RFC.  And versions of TCP that incorporate ECN should be backwards compatible anyway.  And not all versions of TCP will incorporate it even after it's a standard.  Sigh, life is so complicated.  Ngriffeth 19:32, 11 July 2007 (UTC)
replies: text:  The above discussion actually supports my argument.  It's hard to track the changes to RFC's, and it's an unnecessary burden in maintaining a wikipedia article, which (correct me if I'm wrong) is intended for a layperson, not an expert.  Only an expert needs the level of detail we just got into. Also, back to my biggest concern, even if the diagrams are appropriate it's a bad idea to confound the IP and TCP headers this way.  Convinced yet?  (Excuse my verbosity, I'm just excited to talk to someone who cares about this stuff :-). )   And I'm definitely open to leaving it if there's a chance it could be more useful than a link to the IETF.  Ngriffeth 19:32, 11 July 2007 (UTC)
replies: text:  I tried to clarify as best I could by adding headers to the TCP header tables, and breaking them into sections. --Unixguy 15:01, 13 July 2007 (UTC)
replies: text:  Yes, that helps.  I'm gong to put in a pointer to RFC 3168 for the flag fields. Ngriffeth 17:15, 13 July 2007 (UTC)

text:  1. Great work. 2. I'm so evil. :) There are so many threads on forums around the world, you all have probably been involved yourselves at some point, where people either complain about their high speed broadband not downloading at the speeds they expect, OR their little Gigabit home networks fail to run at true Gigabit speeds and they don't know why. The explanation for how Windowing for high speed high latency (in relative terms) as set out in http://tools.ietf.org/html/rfc1323 leaves a bit to be desired, especially in reagards to what gets changed in the TCP Segment when rfc1323 is implemented at both ends. Surely it must be possible to provide a decent explanation in more or less the same amount of words / space as is currently alloted to http://en.wikipedia.org/wiki/SYN_Packet#TCP_window_size . This article is marked as confusing or unclear for some readers before I showed up, so lets see what we can do, hey? That is to say, I have some technical knowledge about TCP-IP and I will try to bring to your attention sections that make me feel I know less than I did, before I read that section, that is to say, if somebody who supposedly has idea of what something is, is confused, hows your regular wikipedia reader going to fair?. :) --Whisper555 18:23, 31 July 2007 (UTC)
thread_title:  [http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure TCP segment structure] 

message: what does this do?
Read the TCP article ;) Burningmace 20:22, 23 July 2007 (UTC)
replies: text: TCP is Great for cleaning tubs, but in this context, it is a method or proticall, much like the proticall Bocce, it is great for negotiating the transfer of binay and ascii data in short bursts or long transfers, for HTTP transmissions or FTP transmissions. ( Jumbo packets are best for faster connectsions ).  —Preceding unsigned comment added by 67.174.157.126 (talk) 02:45, 6 May 2008 (UTC)
thread_title:  what is tcp actually for? 

message: Reading this page just made my brain leak.--163.248.159.162 (talk) 18:32, 3 September 2008 (UTC)
replies: text: Yeah, it' unfortunately bad written. --178.197.225.145 (talk) 14:05, 14 January 2014 (UTC)
thread_title:  This page. 

message: This article states that Nagle is an algorithm for avoiding the silly window syndrome. That is just plain wrong, and should also be obvious if you follow the link to the Nagle algorithm, which describes it. Nagle is for avoiding silly small packets, not silly small windows. There is a very important difference between these, as they occur for very different reasons. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)
thread_title:  Error on Nagle 

message: The boxes for the closing procedures are incorrectly explaining them as active/passive opens.  —Preceding unsigned comment added by 212.146.94.66 (talk) 12:01, 15 September 2008 (UTC)
thread_title:  The TCP state diagram is inaccurate 

message: The article refers to RFC 793 as "TCP v4" in two places.
Why? I've heard TCPv4 used, rarely, to mean "TCP on top of IPv4",
as opposed to "on top of IPv6", but I'm not sure that's
what the article is aiming for. It's not particularly interesting either.
The RFC itself doesn't mention "v4" or "version 4".
And it sure doesn't claim there were ever any TCP v1, v2, or v3.
JöG (talk) 20:53, 12 November 2008 (UTC)
thread_title:  TCP v4 ? 

message: The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet.
This sentence is misleading. Modern TCP implementations will send multiple packets before waiting for an acknowledgment.
--Jeoth (talk) 04:18, 19 December 2009 (UTC)
thread_title:  acknowledgemnts 

message: Section 4.3 says that UDP checksums are optional.  This is true for IPv4, but not for IPv6.
130.221.224.7 (talk) 02:51, 11 March 2011 (UTC)
replies: text: I removed the UDP comparison. It didn't seem necessary. Correcting it would have brought us even further off point. --Kvng (talk) 02:45, 13 March 2011 (UTC)
thread_title:  UDP checksum is required in IPv6 

message: I read right in the beginning: "TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP." Are you ok? Somebody is loosing fuck*** ground here. --Javalenok (talk) 12:59, 28 April 2011 (UTC)
thread_title:  IP component to complemet IP 

message: Whoever added the last part in Connection Termination, can you please add some more details. I have a graduate degree in CS, but I still did not clearly understand this part: "Some application protocols may violate the OSI model layers, using the TCP open/close handshaking for the application protocol open/close handshaking - these may find the RST problem on active close." The example code is showing how NOT to do it, can you also post how to DO it? Also more clarification needed here: "For a usual program flow like above, a TCP/IP stack like that described above does not guarantee that all the data arrives to the other application." Thanks.  — Preceding unsigned comment added by 64.134.66.244 (talk) 00:14, 12 July 2011 (UTC)
thread_title:  Unclear section 4.10 Connection Termination 

message: Just to document edit. Internet radio uses TCP. Most internet radio stations are played with a delay, thus TCP packet recovery can be used.  For Multi room audio (such as in Sonos, Streamium, Apple Airtunes) UDP makes for a simpler implementation. However some systems will still use a TCP implementation since it reduces the implementation overhead. For this you need to synch clocks  — Preceding unsigned comment added by Ursushoribilis (talk • contribs) 09:10, 21 August 2011 (UTC)
thread_title:  TCP is used in internet radio, but not always for multi room audio 

message: This is wrong and need to be corrected. http://www.stratus.com/blog/openvos/?p=749 --Frederico1234 (talk) 13:58, 1 September 2011 (UTC)
thread_title:  "TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another" 

message: "If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168)."
This sentence makes no sense...  — Preceding unsigned comment added by 24.246.4.28 (talk) 14:04, 24 September 2011 (UTC)
replies: text: Many sentences in this article make no sense whatsoever. I don't want to offend anybody, but some things should be rewritten for that at least English speaking tech (!) people can understand it. --178.197.225.145 (talk) 14:08, 14 January 2014 (UTC)
thread_title:  uhhh. what? 

message: Everyone kindly is invited to take part in the discussion to rename Category:TCP/IP, please see: 
Wikipedia:Categories for discussion/Log/2012_August_9#Category:TCP/IP. -- intgr [talk] 16:07, 13 August 2012 (UTC)
thread_title:  Category for discussion: [[:Category:TCP/IP]] -> TCP / Transmission Control Protocol 

message: This article uses both terms. Should we choose one or the other. Please discuss at Wikipedia_talk:WikiProject_Computing/Computer_networking_task_force#Octets_vs._bytes. ~KvnG 14:20, 16 August 2013 (UTC)
thread_title:  Octets vs. bytes 

message: There are two versions of the TCP state diagram in this article, :File:Tcp state diagram fixed.svg (currently used) and :File:Tcp state diagram fixed new.svg (currently up for deletion). For those who cannot see the difference, the second has an ACK/- on the transition between Closing and Time/Wait on the "Active Close" path. I'm not really much of an expert, but I think that is the correct version - with my opinion influenced by de:Transmission Control Protocol, which uses :File:Tcp_verbindung.png, which has the ACK/- in question. Can we get a consensus on which of the images to use? --Stephan Schulz (talk) 11:27, 4 January 2014 (UTC)
replies: text: The new diagram is correct. The non-bold "ACK/-" means that an ACK message is received, and that no message is sent; it is the receipt of an ACK that causes the transition from CLOSING to TIME WAIT. The source is RFC 793 (hard-to-read ASCII art), and a clearer diagram (which a quick look makes me think is correct) is here. Johnuniq (talk) 00:09, 5 January 2014 (UTC)
thread_title:  Choice of diagrams 

message: Dear editors, there is an orphaned article called TO-TCP (terminal originated TCP) that has been marked for deletion. Do any of you see any reason to rescue it? Thanks in advance. TheAMmollusc (talk) 11:54, 15 May 2014 (UTC)
thread_title:  Orphaned article about to be deleted 

message: The link to visualland.net seems to be broken, which is a shame as animations are always useful. We should consider removing the link. Kthelgason 22:44, 18 September 2014 (UTC)
thread_title:  Broken link in "Other" 

message: Today  redirects here to Transmission Control Protocol.
Is there a more general article that discusses sequence numbers, that would be more appropriate for sequence number to redirect to?
While the most common sequence numbers may be TCP sequence numbers,
I see that many other Wikipedia articles mention sequence numbers of various sizes --
alternating bit protocol, B protocol, High-Level Data Link Control, etc. --
none of which are TCP sequence numbers.
My understanding is that many of those protocols are examples of a sliding window protocol.
A few Wikipedia articles mention sequence numbers that are used in things that don't seem to be a sliding window protocol, such as YAFFS and Common Log File System.
Is TCP a sliding window protocol?
(One commenter at talk: sliding window protocol seems to think it is not).
Is there a more general article that would be better for sequence number to redirect to, perhaps an article that discusses a more general category of things that use sequence numbers?
--DavidCary (talk) 18:39, 4 February 2015 (UTC)
replies: text: Perhaps it should be a disambiguation page instead? Or at least start it that way, to see what different kinds of sequence numbers show up and if a general article on the topic even makes sense. -- intgr [talk] 19:12, 4 February 2015 (UTC)
replies: text: Agreed. @DavidCary: Hope you don't mind but I edited your comment to use . Yes, TCP uses a sliding window and it is quite likely that a technical person wanting information about "sequence number" on the Internet is thinking of its use in TCP. However, as you say, there are lots of other topics. A dab page to start would be best. Johnuniq (talk) 09:02, 5 February 2015 (UTC)
thread_title:  sequence number 

message: Hello fellow Wikipedians,
I have just added archive links to  on Transmission Control Protocol. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive http://web.archive.org/web/20110312114242/http://www.ilmondodelletelecomunicazioni.it:80/english/telematics/protocols.html to http://www.ilmondodelletelecomunicazioni.it/english/telematics/protocols.html
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
Cheers.—cyberbot IITalk to my owner:Online 14:52, 27 February 2016 (UTC)
thread_title:  External links modified 

message: That table showing tcp content is confusing. It is using octets, bits and offsets but you can figure out which is which. Colums and rows are impossible to follow and read corectly.  — Preceding unsigned comment added by 86.123.128.88 (talk) 13:00, 13 April 2016 (UTC)
replies: text: If you're talking about Transmission Control Protocol#TCP segment structure, I think it's fairly clear. Each row is 32 bits (4 octets) and the columns refer to bits or fields within each 32-bit unit. This is also the same format how the RFC specifies the TCP header. If you have suggestions for improving it, go ahead. -- intgr [talk] 11:49, 14 April 2016 (UTC)
thread_title:  Confusing table 

message: There's no 200ms delay on send. That's the "delayed ACK" timer, which is at the receive end. TCP does not have an accumulation timer, like an X.25 PAD does. This only affects special situations where the sender sends multiple small packets which don't generate responses. It doesn't affect bulk file transfers. John Nagle (talk) 23:29, 18 August 2016 (UTC)
replies: text: It's possible to meet very informed people at Wikipedia! I once had a reasonable grasp of Nagle's algorithm but that was years ago, and only as a user of TCP/IP. I see that the wording is wrong—I guess the point they attempted to make is that if a process at A sends 1 byte to TCP for delivery to B, then B will wait for 200 ms before replying with an ACK (assuming no data from B to A is sent). Meanwhile, assuming the process at A sends more, the TCP at A will wait for the ACK before sending the additional data. So, after the first byte, there is a delay before another byte is sent, and the delay may be up to 200 ms plus round-trip time. Any chance of some suggested wording to fix the section? Johnuniq (talk) 11:17, 19 August 2016 (UTC)
replies: text:  Right. But that delay only applies to packets smaller than the maximum packet size. If there's enough data to fill a packet, it goes out anyway. This is done to prevent sending lots of tiny packets instead of one big one. John Nagle (talk) 06:41, 20 August 2016 (UTC)
replies: text: Understood—it's hard making a simple statement about TCP that covers all cases! Johnuniq (talk) 07:01, 20 August 2016 (UTC)
thread_title:  Forcing data delivery section is wrong 

message: " [...]the client must allocate a random port before sending the first SYN to the server. This port remains allocated during the whole conversation, and effectively limits the number of outgoing connections from each of the client's IP addresses. If an application fails to properly close unrequired connections, a client can run out of resources and become unable to establish new TCP connections, even from other applications."
This part is not clear -- how is the fact that the client allocates a port upon connection "effectively limits the number of outgoing connections from each of the client's
IP address"? Is it because there is a "limited number of ports"? What limit is refereed to here?
YuvalAloni (talk) 17:44, 20 December 2016 (UTC)
replies: text: It's a long time since I thought much about TCP but I think the text is based on the premise that a server is probably running a small number of well-designed applications where things that are opened are eventually closed, so the server is good. However, anyone can write code for a typical client, and bad code might not close connections. The port is specified with a 16-bit number, so 65536 ports are available for TCP at a server and at a client. That is the limit, and really broken software could use all the ports which would prevent further connections. The same consideration applies at the server which generally listens on port 0. However, the server will establish a TCP connection on a randomly chosen port so there is no difference between the server and client. Johnuniq (talk) 03:29, 21 December 2016 (UTC)
thread_title:  Resource usage 

message: Could someone please tell why only TIME_WAIT is marked "either server or client"? Is there any problem if we state "both server and client" for this one too? --Kuratowski (talk | contribs) 11:10, 3 October 2017 (UTC)
thread_title:  Protocol Operation 

message: Problem:
I propose translate from the french Wikipedia Transmission Control Protocol (according to the licensing rules):
Plase consider it, thanks! --Jimmy Olano (talk) 18:41, 4 August 2019 (UTC)
replies: text: I don't think we would improve things by replacing the current lead with what you propose. Maybe we could merge the two together. The real problem here is that, while what we have is a competent high-level description of TCP, we're missing a summary a lot of the content in the body of the article. ~Kvng (talk) 13:31, 7 August 2019 (UTC)
replies: text:  You are right: I want substitute the summary, I am using only the WP:TECHNICAL style. Let's wait and think better, meanwhile others wikipedians may contribute too; have a nice day!--Jimmy Olano (talk) 14:03, 7 August 2019 (UTC)

text: I think it's good and removed the tag, thanks. Johnuniq (talk) 02:51, 27 December 2019 (UTC)
thread_title:  Adequate summary 

message: An editor has asked for a discussion to address the redirect TCPSTACK. Please participate in the redirect discussion if you wish to do so.  Steel1943 (talk) 07:23, 26 January 2020 (UTC)
thread_title:  "TCPSTACK" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: This page by Vskills seem to derive from the Connection establishment to the Connection termination sections, without crediting the editors of those sections or linking to this article. Major contributors to those sections, as well as the uploader of :File:TCP CLOSE.svg might want to talk to the website's admin about it. pandakekok9 (talk) 11:42, 23 July 2021 (UTC)
thread_title:  Possible reverse copyvio 

message: Is it possible to add arrow heads and labels (t for time) at bottom of the Connection termination figure, which is a sequence diagram?  This would help clarity. — Preceding unsigned comment added by Brutzman (talk • contribs) 15:49, 6 August 2021 (UTC)
replies: text: Time increases in the down direction in these diagrams but not necessarily in proportion to distance. It is describing a sequence of events one following another as per the indicated arrows. If we turned it upside down or sideways, it would still make sense without labeling time. ~Kvng (talk) 18:00, 13 August 2021 (UTC)
thread_title:  What about time arrows on sequence diagram?  

message: The introduction has citations only for wikipedia. Having some sources outside of this website would be lovely. - MountainKemono (talk) 15:38, 6 December 2022 (UTC)
replies: text: We don't require citations in the lead per WP:WHENNOTCITE. That said, there is not good support for the assertion that  in the body of the article. This is not a controversial statement IMO and is well supported (but not clearly well cited) in Internet protocol suite. ~Kvng (talk) 16:09, 11 December 2022 (UTC)
replies: text: My apologies for the way I worded that. I believe that is what I was trying to point out in the introduction. I will have to do some source finding to see where that takes me and update appropriately. - MountainKemono (talk) 10:45, 12 December 2022 (UTC)
thread_title:  Citation would be nice on the opening paragraph.